広告
広告
https://www.7key.jp/rfc/3339/rfc3339_4.html#sourcehttps://www.7key.jp/rfc/3339/rfc3339_4.html#translationBecause the daylight saving rules for local time zones are so convoluted and can change based on local law at unpredictable times, true interoperability is best achieved by using Coordinated Universal Time (UTC). This specification does not cater to local time zone rules.
地域時間帯のサマータイム規則はとても難解で、更に地域ごとの法律によって突然その規則は変更されることがあるため、真の相互運用性を得るには世界協定時（UTC）を用いることが近道である。このため、当仕様書では地域時間帯の規則については言及しない。
The offset between local time and UTC is often useful information. For example, in electronic mail (RFC2822, [IMAIL-UPDATE]) the local offset provides a useful heuristic to determine the probability of a prompt response. Attempts to label local offsets with alphabetic strings have resulted in poor interoperability in the past [IMAIL], [HOST-REQ]. As a result, RFC2822 [IMAIL-UPDATE] has made numeric offsets mandatory.
現地時間とUTCの間のオフセットは有用な情報である。例えば、電子メール（RFC2822, [IMAIL-UPDATE]）でのローカルオフセットにおいては、迅速なレスポンスの可能性を探るために有用な試行錯誤が繰り返された。アルファベット文字をローカルオフセットのラベルとする試みは、古い[IMAIL]や[HOST-REQ]において互換性の低下を招いた。その結果として、RFC2822[IMAIL-UPDATE]では数値で表すオフセットが必須とされた。
Numeric offsets are calculated as "local time minus UTC". So the equivalent time in UTC can be determined by subtracting the offset from the local time. For example, 18:50:00-04:00 is the same time as 22:50:00Z. (This example shows negative offsets handled by adding the absolute value of the offset.)
数値で表すオフセットは、「現地時間からUTCを減算する」ことによって算出される。つまり、現地時間からオフセットを減算することによりUTCでの時間が算出できることとなる。例えば、"18:50:00-04:00"は"22:50:00Z"と同時刻である（この例は、オフセットの絶対値を加えることにより、マイナス値を取るオフセットの処理が可能ことを表している）。
NOTE: Following ISO 8601, numeric offsets represent only time
zones that differ from UTC by an integral number of minutes.
However, many historical time zones differ from UTC by a non-
integral number of minutes. To represent such historical time
stamps exactly, applications must convert them to a representable
time zone.
注記：ISO8601によると、数値で表すオフセットは整数の分単位でUTCと異なる時間帯のみを表すとされている。しかし実在する時間帯の多くは、非整数の分単位でUTCと異なっている。よって、精確にこれらのタイムスタンプを表すためには、アプリケーションが表示可能な時間帯に変換しなければならない。
If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "-00:00". This differs semantically from an offset of "Z" or "+00:00", which imply that UTC is the preferred reference point for the specified time. RFC2822 [IMAIL-UPDATE] describes a similar convention for email.
UTCでの時間が判り現地時間のオフセットが判らない場合、オフセットを"-00:00"と表現する。これは、UTCが指定した時間の優先的な参照ポイントとなるオフセット"Z"や"+00:00"とは意味的に異なる。RFC2822[IMAIL-UPDATE]にて、電子メールのための類似の慣習について触れられている。
A number of devices currently connected to the Internet run their internal clocks in local time and are unaware of UTC. While the Internet does have a tradition of accepting reality when creating specifications, this should not be done at the expense of interoperability. Since interpretation of an unqualified local time zone will fail in approximately 23/24 of the globe, the interoperability problems of unqualified local time are deemed unacceptable for the Internet. Systems that are configured with a local time, are unaware of the corresponding UTC offset, and depend on time synchronization with other Internet systems, MUST use a mechanism that ensures correct synchronization with UTC. Some suitable mechanisms are:
現在インターネットに接続する装置の多くは、現地時間を示す内部時計で動作しておりUTCについては無関心である。インターネットの仕様書は現実に沿うよう策定される慣例を持つが、これは相互運用性を犠牲にしてまで守る慣例ではない。不適格な現地時間帯の解釈は地球上の全地域の23/24で失敗すると予想され、不適格な現地時間の相互運用問題はインターネットにおいて承諾し難いと考えられる。現地時間で構成されるシステム、又はUTCオフセットを認識しないシステム、他のインターネットシステムを備えた時間同期機構に依存するシステムは、UTCを備えた精確な同期を保証するメカニズムを用いなければならない（MUST）。それに見合う機構は下記：
o Use Network Time Protocol [NTP] to obtain the time in UTC.
UTC時を得るためにNTPを用いる。
o Use another host in the same local time zone as a gateway to the
Internet. This host MUST correct unqualified local times that are
transmitted to other hosts.
同じ現地時間帯の他のホストをインターネットゲートウェイとして用いる。このホストは、他のホストから伝達される不適格な現地時間を修正しなくてはならない（MUST）。
o Prompt the user for the local time zone and daylight saving rule
settings.
現地時間帯とサマータイム規則の設定をユーザに促す。
広告