Link timezone localtime
timezone が - の場合、既存のリンクは削除されます。
Link timezoneposixrules
timezone が (既定値)の場合、既存のリンクはすべて削除されます。
timezone が でない限り、このオプションは廃止され、ほとんどのランタイムでサポートされなくなりました。特に、2037年以降のタイムスタンプには使用すべきではありません。また、timezone の遷移が現地時間ではなく標準時または UT である場合は、-b slim と組み合わせるべきではありません。このオプションは、遷移ルールのない "AST4ADT" のような廃止された TZ 文字列を処理するときにtimezone のルールを使用した廃止されたランタイムをサポートするためにのみ存在します。これらの TZ 文字列をサポートする最新のランタイムは、 TZ 文字列が主に米国で使用されていたため、通常は現在の米国のルールを使用します。同様に、"posixrules"という名前のゾーンまたはリンクは廃止され、問題があります。
入力はリンクへのリンクを指定しますが、これは zic 自体からリリース 2022e までを含む一部の古いパーサーではサポートされていません。
データファイルに表示される年は、表示可能な年の範囲外です。
24:00 以上の時刻が入力に表示されます。1998 より前のバージョンの zic では24:00 が禁止されており、2007 より前のバージョンでは 24:00 を超える時刻が禁止されています。
月の初めまたは終わりを過ぎたルール。2004 より前のバージョンの zic では、これは禁止されています。
タイムゾーンの省略形は %z 形式を使用します。2015 より前のバージョンの zic はこれをサポートしていません。
タイムスタンプには小数秒が含まれます。2018 より前のバージョンの zic はこれをサポートしていません。
入力には、長年のコーディングバグのために 2018 以前のバージョンの zic で誤って処理される略語が含まれています。これらの略語には、 の場合は 、 の場合は 、 の場合は 、 の場合は が含まれます。
将来は TZ の予兆文字列としてまとめることができないため、出力されるファイルには、あるタイムゾーンの長期的な将来に関するすべての情報が含まれているわけではありません。例えば、 2023 の時点では、この問題は夏時間規則で発生します。これらの規則は、TZ の予兆文字列では表現できない、ラマダンがいつ行われるかの予測に基づいているからです。
出力には、古い zic 形式用に設計されたクライアント・コードでは適切に処理できない可能性のあるデータが含まれています。これらの互換の問題は、 1970 前または 2038 開始後のタイムスタンプにのみ影響します。
出力には切り捨てられた閏秒テーブルが含まれているため、一部の古い TZif リーダーでは誤動作が発生する可能性があります。これは、-L オプションが使用され、Expires 行が存在するか、-r オプションも使用されている場合に発生する可能性があります。
出力されたファイルには、一部のクライアントで誤って処理される可能性のある 1200 遷移以外の遷移が含まれています。現在のリファレンスクライアントは、ほとんどの 2000 遷移をサポートしていません。2014 より前のバージョンのリファレンスクライアントは、ほとんどの 1200 遷移をサポートしています。
タイムゾーンの省略形が 3文字未満または 6文字を超えています。POSIX では少なくとも 3文字が必要であり、実装では少なくとも 6文字をサポートする必要があります。
出力されたファイルに、ASCII 文字ではないバイト 、 、または が含まれているか、14 バイトより長い文字で構成されるか、または で始まるファイルが含まれています。
入力ファイルはテキストファイルである必要があります。つまり、0個以上の行で構成され、それぞれが改行バイトで終わり、改行をカウントする最大 2048 バイトを含み、NUL バイトを含まないものである必要があります。入力テキストのエンコーディングは通常 UTF-8 または ASCII です。 POSIX Portable Character Set(PPCS) の1バイト表現を持つ必要があります。また、エンコーディングの非1バイト文字はすべて非 PPCS バイトで構成する必要があります。非 PPCS 文字は通常、コメント内でのみ使用されます。出力ファイル名とタイムゾーンの省略形にはほとんどすべての文字を含めることができますが、-v オプションで説明されている制限された構文に限定されている場合は、他のソフトウェアの方がうまく動作します。
入力行は、フィールドで構成されます。各フィールドは、1つ以上の空白文字で区切られます。空白文字は、スペース、フォーム・フィード、キャリッジ・リターン、改行、タブおよび垂直タブです。入力行の先頭と末尾の空白は無視されます。入力内の引用符で囲まれていないシャープ文字 (#) は、そのシャープ文字が表示される行の末尾までコメントになります。空白文字およびシャープ文字をフィールドの一部として使用する場合は、二重引用符 (¥") で囲むことができます。(コメント・ストリッピング後の)空白の行は無視されます。空白でない行は、ルール行、ゾーン行およびリンク行の3つのタイプのいずれかであると想定されます。
名前は英語で指定する必要があり、大文字と小文字は区別されません。名前は様々なコンテキストで使用され、月名、曜日名および maximum、only、 Rolling、 Zone などのキーワードが含まれます。先頭の接頭辞以外をすべて省略して名前を短縮することもできますが、どの省略形もコンテキスト内で一意である必要があります。
ルール行の書式は以下のようなものです。
ルール行を構成するフィールドは以下の通りです:
Rule NAME FROM TO - IN ON AT SAVE LETTER/S 例:
Rule US 1967 1973 - Apr lastSun 2:00w 1:00d D
5 その月の第 5 日 lastSun その月の最後の日曜日 lastMon その月の最後の月曜日 Sun>=8 第 8 日以降の最初の日曜日 Sun<=25 第 25 日以前の最後の日曜日
曜日名(例: Sunday) または曜日名の前に が付いている場合 (例:lastSunday)は、前述のように省略できます。たとえば、日曜日は 、最後の土曜日は です。ON フィールドには空白文字を使用できません。 および 構文は、結果として次の月の日になることがあります。たとえば、IN-ON の組み合わせ は、10月31日以降の最初の日曜日を表します。その日曜日が 11月であっても同様です。
2 time in hours 2:00 time in hours and minutes 01:28:14 time in hours, minutes, and seconds 00:19:32.13 time with fractional seconds 12:00 midday, 12 hours after 00:00 15:00 3 PM, 15 hours after 00:00 24:00 end of day, 24 hours after 00:00 260:00 260 hours after 00:00 -2:30 2.5 hours before 00:00 - equivalent to 0
zic は時間を最も近い整数秒に丸めますが(偶数整数とのタイを破ります)、分数はより高い精度を必要とする他のアプリケーションに役立つ場合があります。ソースフォーマットは最大精度を指定しません。これらの形式の後には、指定された時間がローカルまたは 時間の場合は文字 w 、指定された時間が夏時間の調整なしの標準時間の場合は s 、指定された時間が世界時の場合は u (または g または z)を続けることができます。インジケータがない場合は、ローカル(ウォールクロック)時間が想定されます。これらの形式は AT 秒を無視します。たとえば、うるう秒がローカル時間の 00:59:60 に発生した場合、 は通常 の3600秒ではなく、ローカル深夜 0時から 3601秒を表します。その意図は、ルール行が、「閏秒」フィールドで指定された時間のタイプに設定されたクロック/カレンダが、指定された日時を表示する瞬間を記述することです。
ゾーン行の書式は以下のようなものです。
ゾーン行を構成するフィールドは以下の通りです:
Zone NAME STDOFF RULES FORMAT [UNTIL] 例:
Zone Asia/Amman 2:00 JordanEE%sT2017 Oct 27 01:00
前のゾーンまたは継続行でルールが有効になるのと同じ時点でゾーンが変更された場合、そのルールは無視されます。名前付きルール・セットを持つゾーンまたは継続行の L は、既定値別の標準時で始まります。つまり、L の最初のルールより前の L のタイムスタンプはすべて、L が標準時に最初に移行した後に有効になるルールを使用します。1つのゾーン内で、2つのルールが同時に有効になった場合、または 2つのゾーンの変更が同時に有効になった場合はエラーになります。
継続行の N オフセットとルールを使用している場合に、より遅いと解釈される遷移の後で、継続行が UT オフセットから UT 秒を引いた場合、前のゾーンまたは継続行の 時間は、継続行の UT オフセットとルールに従って解釈され、次の N 秒で有効になるルールは、代わりに同時に有効になると想定されます。次に例を示します:
# Rule NAME FROM TO - IN ON AT SAVE LETTER/S
Rule US 1967 2006 - Oct lastSun 2:00 0 S
Rule US 1967 1973 - Apr lastSun 2:00 1:00 D
# Zone NAME STDOFF RULES FORMAT [UNTIL]
Zone America/Menominee -5:00 - EST 1973 Apr 29 2:00
-6:00 US C%sT
ここでは、1973-04-29 に 2回のクロック変更があったという誤った解釈があります。1回目はゾーン行の 値に従って 02:00 EST (-05) から 01:00 CST (-06) へ、2回目は 4月のルール行の値に従って 1時間後の 02:00 CST(-06) から 03:00 CDT (-05) への変更です。ただし、 zic はこれを 02:00 EST (-05) から 02:00 CDT (-05)への単一の移行としてより合理的に解釈しています。
リンク行の書式は以下のようなものです。
TARGET フィールドは、ゾーン行では NAME フィールドとして表示されるか、リンク行では LINK-NAME フィールドとして表示されます。LINK-NAME フィールドは、そのゾーンの別名として使用されます。構文は、ゾーン行の NAME フィールドと同じです。リンクは連鎖できますが、1つ以上のリンクの連鎖がゾーン名で終了しない場合の動作は指定されていません。リンク・ターゲットを定義する行の前に、リンク行を表示できます。次に例を示します:
Link TARGET LINK-NAME 例:
Link Europe/IstanbulAsia/Istanbul
Link Greenwich G_M_T Link Etc/GMT Greenwich Zone Etc/GMT 0 - GMT2つのリンクはチェーンされ、G_M_T、Greenwich、Etc/GMT はすべて同じゾーンに名前を付けます。
継続行を除き、行は入力内で任意の順序で出現できます。ただし、複数のゾーンまたはリンク行が同じ名前を定義した場合の動作は指定されていません。
閏秒を記述するファイルには、閏行と有効期限行を含めることができます。閏行の形式は次のとおりです:
YEAR、MONTH、DAY、および HH:MM:SS フィールドは、閏秒がいつ発生したかを示します。CORR フィールドは、秒が追加された場合は 、秒がスキップされた場合は になります。R/S フィールドは、他のフィールドで指定された閏秒が UTC として解釈される場合は の省略形になり、他のフィールドで指定された閏秒がローカル(壁時計)時間として解釈される場合は の省略形になります。
Leap YEAR MONTH DAY HH:MM:SS CORR R/S 例:
Leap 2016 Dec 31 23:59:60 + S
ローリングうるう秒は、 カウントダウンがある、タイムズスクエアのボールが落ちる所で見ることができ、閏秒を UTC の真夜中ではなくニューヨーク時間の真夜中に配置します。移動しない閏秒が一般的な方法ですが、ローリング閏秒は、ローカルでの放送終了時に閏秒の不連続性を置くことを好む SMPTE タイムコードのような特殊なアプリケーションで有用です。ただし、-r オプションが使用されている場合、ローリング閏秒はサポートされません。
有効期限行は、存在する場合、次の形式になります:
YEAR、MONTH、DAY、および HH:MM:SS フィールドは、閏秒テーブルの有効期限タイムスタンプを UTC で示します。
Expires YEAR MONTH DAY HH:MM:SS 例:
Expires 2020 Dec 28 00:00:00
# Rule NAME FROM TO - IN ON AT SAVE LETTER/S
Rule Swiss 1941 1942 - May Mon>=1 1:00 1:00 S
Rule Swiss 1941 1942 - Oct Mon>=1 2:00 0 -
Rule EU 1977 1980 - Apr Sun>=1 1:00u 1:00 S
Rule EU 1977 only - Sep lastSun 1:00u 0 -
Rule EU 1978 only - Oct 1 1:00u 0 -
Rule EU 1979 1995 - Sep lastSun 1:00u 0 -
Rule EU 1981 max - Mar lastSun 1:00u 1:00 S
Rule EU 1996 max - Oct lastSun 1:00u 0 -
# Zone NAME STDOFF RULES FORMAT [UNTIL]
Zone Europe/Zurich 0:34:08 - LMT 1853 Jul 16
0:29:45.50 - BMT 1894 Jun
1:00 Swiss CE%sT 1981
1:00 EU CE%sT
Link Europe/Zurich Europe/Vaduz
この例では、EU 規則は欧州連合 (EU) とその先行組織である欧州共同体 (EC) に適用されます。タイムゾーンの名前は Europe/Zurich で、別名は Europe/Vaduz です。この例では、Zurich は 1853-07-16の00:00 まで UT の東 34分 8秒にあり、このとき有効なオフセットは 7degrees26分22.50秒 に変更され、0:29:45.50 になります。zic はこれを 0:29:46 に丸めて処理します。1894-06-01 の 00:00 以降、UT オフセットは 1時間になり、スイスの夏時間規則 ( が適用されます。1981年から現在まで、EU の夏時間規則が適用され、UTC オフセットは1時間のままです。
1941年と 1942年には、夏時間は 5月の第 1月曜日の 01:00 から 10月の第 1月曜日の 02:00 まで適用されました。1981 年以前の EU 夏時間規則はここでは効果がありませんが、完全性のために含まれています。1981年以降、夏時間は 3月の最後の日曜日の 01:00 UTC に開始されました。1995年までは 9月の最後の日曜日の 01:00 UTC に終了していましたが、これは 1996年から 10月の最後の日曜日に変更されました。
表示の目的で、 と がそれぞれ最初に使用されました。スイスの規則とその後の EU の規則が適用されて以来、タイムゾーンの省略形は、標準時は CET、夏時間は CESTとなっています。
特定のタイムゾーンで、夏時間の開始によるクロックの進みが、UT オフセットの変更によるクロックの戻りと一致し、等しい場合、zic は、ローカル(壁時計)時間の変更なしに、新しい UT オフセットで夏時間への単一の移行を生成します。個別の移行を取得するには、世界時を使用して移行の瞬間を指定する複数のゾーン継続行を使用します。