GK at ninebynine.org
Tue Feb 15 08:37:40 EST 2005
At 02:38 15/02/05 -0800, Ashley Yakeley wrote:
>In article <126.96.36.199.2.20050215100243.02f5de40 at 127.0.0.1>,
> Graham Klyne <GK at ninebynine.org> wrote:
> > Yes, something like that... RFC3339 has a trick of using -00:00 offset for
> > this:
> > [[
> > 4.3. Unknown Local Offset Convention
> > If the time in UTC is known, but the offset to local time is unknown,
>That's not what I meant at all. A CalendarTime without a time zone is a
>local time, with no information about time zone or time in UTC.
Oops, sorry, you're absolutely right. It's been a while, I mentally
misplaced the detail, and failed to notice that when I hooked out the text.
In fact, in the case of RFC3339, which is intended to be used for Internet
protocol timestamps, the unqualified local time case is not supported, and
doesn't really provide any support for this case:
4.4. Unqualified Local Time
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:
o Use Network Time Protocol [NTP] to obtain the time in UTC.
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.
o Prompt the user for the local time zone and daylight saving rule
Sorry for the confusion. Let normal programming resume.
More information about the Libraries