広告
広告
https://www.7key.jp/rfc/3339/rfc3339_5.html#source
https://www.7key.jp/rfc/3339/rfc3339_5.html#translation
This section discusses desirable qualities of date and time formats and defines a profile of ISO 8601 for use in Internet protocols.
この章は、日付と時間の書式における望ましい特質について論じ、インターネットプロトコルで用いるISO 8601プロフィールを定義するものである。
If date and time components are ordered from least precise to most precise, then a useful property is achieved. Assuming that the time zones of the dates and times are the same (e.g., all in UTC), expressed using the same string (e.g., all "Z" or all "+00:00"), and all times have the same number of fractional second digits, then the date and time strings may be sorted as strings (e.g., using the strcmp() function in C) and a time-ordered sequence will result. The presence of optional punctuation would violate this characteristic.
日付と時刻の構成要素を大雑把なものから精密なものの順番に列記することにより、有用な特性が得られることとなる。日付と時刻の時間帯が同じで(例えば全てUTC)同じ文字列が用いられ(例えば全て"Z"や全て"+00:00")、時間に用いられる全ての数字が2桁に統一されると仮定すれば、日付と時刻を表す文字列は文字列として並べ替えすることが可能で(例えばC言語のstrcmp()関数を用いる)、時系列に並べた結果が得られることとなる。任意に句読点を用いるのであれば、この特性が得られる保証はない。
Human readability has proved to be a valuable feature of Internet protocols. Human readable protocols greatly reduce the costs of debugging since telnet often suffices as a test client and network analyzers need not be modified with knowledge of the protocol. On the other hand, human readability sometimes results in interoperability problems. For example, the date format "10/11/1996" is completely unsuitable for global interchange because it is interpreted differently in different countries. In addition, the date format in [IMAIL] has resulted in interoperability problems when people assumed any text string was permitted and translated the three letter abbreviations to other languages or substituted date formats which were easier to generate (e.g. the format used by the C function ctime). For this reason, a balance must be struck between human readability and interoperability.
人間による判読性がインターネットプロトコルにおいて有益な特徴となることは実証済みである。人間により判読可能なプロトコルは、テストクライアントとしてはtelnetで十分であり、プロトコルの知識によってネットワークアナライザを修正する必要がないため大幅にデバッグコストを削減することとなる。その一方で、人間に拠る判読性が相互互換に関する問題を引き起こすこともある。例えば、"10/11/1996"との日付の書式は、国が異なれば解釈も異なるため地球規模での日付のやり取りに用いるには不適切である。さらに、人はどんな文字列であっても判読可能だと仮定し、3文字の略語を他の言語に翻訳するかもしくは生成がより容易な日付の書式(例えばC言語のctime関数で用いられる書式)で代用したために、[IMAIL]での日付の書式が相互互換問題を引き起こすこととなった。このことから解るように、人間による判読性と互換性のバランスが重要である。
Because no date and time format is readable according to the conventions of all countries, Internet clients SHOULD be prepared to transform dates into a display format suitable for the locality. This may include translating UTC to local time.
全ての国の習慣において統一して読み易い日付と時刻の書式はないのだから、インターネットクライアントは日付を地域に適した表示書式に整形する処理を念頭に置くべきである(SHOULD)。この処理には、UTCを現地時間に直す処理が含まれることもある。
A format which includes rarely used options is likely to cause interoperability problems. This is because rarely used options are less likely to be used in alpha or beta testing, so bugs in parsing are less likely to be discovered. Rarely used options should be made mandatory or omitted for the sake of interoperability whenever possible.
稀にしか用いられないオプションを含む書式は、相互互換に関する問題を引き起こす可能性が高い。これは、稀にしか持ちいられないオプションがアルファもしくはベータテストで用いられる可能性が低く、そのため解析の際のバグが発見される可能性までもが低いことに起因する。可能な限り、稀にしか用いられないオプションは義務とするか、相互互換性のために省略されるべきである。
The format defined below includes only one rarely used option: fractions of a second. It is expected that this will be used only by applications which require strict ordering of date/time stamps or which have an unusual precision requirement.
以降で定義される書式には、1つだけ稀にしか用いられないオプション――秒の少数を表すオプション――が含まれる。これは、日付と時刻を厳密な順序で表すことが必須のアプリケーション、もしくは通常よりも精度の高い要求が必要なアプリケーションによってのみ使われることが期待されるオプションである。
If a date/time format includes redundant information, that introduces the possibility that the redundant information will not correlate. For example, including the day of the week in a date/time format introduces the possibility that the day of week is incorrect but the date is correct, or vice versa. Since it is not difficult to compute the day of week from a date (see Appendix B), the day of week should not be included in a date/time format.
日付と時刻の書式が冗長な情報を含む場合、冗長な情報に相互関連がない可能性をもたらすこととなる。例えば、日付と時刻の書式に曜日を含めた場合、曜日が正しくない可能性をもたらすが、日付が正確なのか曜日が正確なのか判断できない。日付から曜日を算出することは難しくないので(「付記B. 曜日」を参照)、日付と時刻の書式に曜日を含めるべきではない。
The complete set of date and time formats specified in ISO 8601 [ISO8601] is quite complex in an attempt to provide multiple representations and partial representations. Appendix A contains an attempt to translate the complete syntax of ISO 8601 into ABNF. Internet protocols have somewhat different requirements and simplicity has proved to be an important characteristic. In addition, Internet protocols usually need complete specification of data in order to achieve true interoperability. Therefore, the complete grammar for ISO 8601 is deemed too complex for most Internet protocols.
ISO 8601で定義された日付と時間の書式の完全な集合は、多数の表現及び部分的な表現を範囲に含むため非常に複雑である。「付記A. ISO 8601のABNF集」にISO 8601の完全な構文をABNFに変換する試みがある。インターネットプロトコルは多少異なる必要条件を持っており、単純であることが重要な特性であることも実証されている。さらに、インターネットプロトコルは、通常完全な相互互換が求められるためデータの完全な仕様が要求されることとなる。そのため、ISO 8601の完全な文法は、大抵のインターネットプロトコルにおいて複雑すぎるとみなされる。
The following section defines a profile of ISO 8601 for use on the Internet. It is a conformant subset of the ISO 8601 extended format. Simplicity is achieved by making most fields and punctuation mandatory.
次の章は、インターネットで用いられるISO 8601のプロフィールを定義するものである。これは、ISO 8601の拡張書式に従う部分集合であり、殆どのフィールドと句読点を必須とすることにより単純なものとなっている。
The following profile of ISO 8601 [ISO8601] dates SHOULD be used in new protocols on the Internet. This is specified using the syntax description notation defined in [ABNF].
次のISO 8601日付のプロフィールを、新しく勧告するインターネットプロトコルで用いるべきである(SHOULD)。これは、[ABNF]で定義された構文記述法を使い指定される。
date-fullyear = 4DIGIT date-month = 2DIGIT ; 01-12 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on ; month/year time-hour = 2DIGIT ; 00-23 time-minute = 2DIGIT ; 00-59 time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second ; rules time-secfrac = "." 1*DIGIT time-numoffset = ("+" / "-") time-hour ":" time-minute time-offset = "Z" / time-numoffset partial-time = time-hour ":" time-minute ":" time-second [time-secfrac] full-date = date-fullyear "-" date-month "-" date-mday full-time = partial-time time-offset date-time = full-date "T" full-time
NOTE: Per [ABNF] and ISO8601, the "T" and "Z" characters in this syntax may alternatively be lower case "t" or "z" respectively.
注記:[ABNF]とISO 8601において、この構文の文字"T"と"Z"はそれぞれ小文字で"t"と"z"と表されることがある。
This date/time format may be used in some environments or contexts that distinguish between the upper- and lower-case letters 'A'-'Z' and 'a'-'z' (e.g. XML). Specifications that use this format in such environments MAY further limit the date/time syntax so that the letters 'T' and 'Z' used in the date/time syntax must always be upper case. Applications that generate this format SHOULD use upper case letters.
この日付と時刻の書式は、(例えばXMLのように)大文字'A'-'z'と小文字'a'-'z'を区別する環境や文脈で用いられる可能性がある。このような環境において当書式を用いる仕様書は、日付と時刻の構文で使う文字'T'と'Z'を常に大文字とするようその構文に制限を加えてもよい(MAY)。この書式を生成するアプリケーションは大文字を用いるべきである(SHOULD)。
NOTE: ISO 8601 defines date and time separated by "T". Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character.
注記:ISO 8601は、"T"によって区切られた日付と時刻を定義する。この構文を用いるアプリケーションは読み易さのために、空白で区切った完全な日付と完全な時刻の指定を選択することがある。
The grammar element date-mday represents the day number within the current month. The maximum value varies based on the month and year as follows: Month Number Month/Year Maximum value of date-mday ------------ ---------- -------------------------- 01 January 31 02 February, normal 28 02 February, leap year 29 03 March 31 04 April 30 05 May 31 06 June 30 07 July 31 08 August 31 09 September 30 10 October 31 11 November 30 12 December 31 Appendix C contains sample C code to determine if a year is a leap year.
date-mdayは、現在の月を番号で示す文法要素である。最大値は以下のように月と年に基づいて異なる:
「付記C. うるう年」で、その年がうるう年であるかどうかを判断するサンプルCコードを紹介している。
The grammar element time-second may have the value "60" at the end of months in which a leap second occurs -- to date: June (XXXX-06- 30T23:59:60Z) or December (XXXX-12-31T23:59:60Z); see Appendix D for a table of leap seconds. It is also possible for a leap second to be subtracted, at which times the maximum value of time-second is "58". At all other times the maximum value of time-second is "59". Further, in time zones other than "Z", the leap second point is shifted by the zone offset (so it happens at the same instant around the globe).
文法要素であるtime-secondは、うるう秒の発生する月の月末に値"60"を取ることがある(6月:XXXX-06-30T23:59:60Z、又は12月:XXXX-12-31T23:59:60Z)。うるう秒の一覧については「付記D. うるう秒」を参照のこと。うるう秒は少なくなる可能性もあり、その際time-secondの取り得る最大値は"58"となる。他の場合、time-secondの取り得る最大値は"59"である。さらに、"Z"以外の時間帯では、うるう秒ポイントはゾーンオフセットによって変更される(つまり、うるう秒は地球全体で同時に発生する)。
Leap seconds cannot be predicted far into the future. The International Earth Rotation Service publishes bulletins [IERS] that announce leap seconds with a few weeks' warning. Applications should not generate timestamps involving inserted leap seconds until after the leap seconds are announced.
将来のうるう秒は予測不可能である。国際地球自転サービスは、数週間の警告を備えたうるう秒を発表する公報[IERS]を刊行する。アプリケーションは、うるう秒が発表されるまでうるう秒を含むタイムスタンプを生成するべきではない。
Although ISO 8601 permits the hour to be "24", this profile of ISO 8601 only allows values between "00" and "23" for the hour in order to reduce confusion.
ISO 8601では"24"時が認められているが、このISO 8601プロフィールでは混乱を避けるために"00"から"23"の時間の値だけを認めるものとする。
Here are some examples of Internet date/time format.
いくつかのインターネット日付/時間書式の例を挙げる:
1985-04-12T23:20:50.52Z This represents 20 minutes and 50.52 seconds after the 23rd hour of April 12th, 1985 in UTC.
これはUTCで、1985年4月12日23時20分と50.52秒を表している。
1996-12-19T16:39:57-08:00 This represents 39 minutes and 57 seconds after the 16th hour of December 19th, 1996 with an offset of -08:00 from UTC (Pacific Standard Time). Note that this is equivalent to 1996-12-20T00:39:57Z in UTC.
これはUTCからのオフセット-08:00(太平洋標準時間)で、1996年12月19日16時39分57秒を表している。これはUTCでの1996-12-20T00:39:57Z
と同値である。
1990-12-31T23:59:60Z This represents the leap second inserted at the end of 1990.
これは1990年の終りに加えられるうるう秒を表している。
1990-12-31T15:59:60-08:00 This represents the same leap second in Pacific Standard Time, 8 hours behind UTC.
これはUTCより8時間遅い太平洋標準時間での同じうるう秒を表している。
1937-01-01T12:00:27.87+00:20 This represents the same instant of time as noon, January 1, 1937, Netherlands time. Standard time in the Netherlands was exactly 19 minutes and 32.13 seconds ahead of UTC by law from 1909-05-01 through 1937-06-30. This time zone cannot be represented exactly using the HH:MM format, and this timestamp uses the closest representable UTC offset.
これはオランダ時間で、1937年1月1日の正午を表している。オランダでの標準時間は、1909-05-01から1937-06-30の間法律によってUTCより精確に19分32.13秒進んでいた経緯がある。この時間帯はHH:MM書式を用いて正確に表すことができず、このタイムスタンプは最も近い表示可能なUTCオフセットを用いている。
広告