Re: Calendar Types

15 Feb 2005

      At 02:38 15/02/05 -0800, Ashley Yakeley wrote:
...
In article <5.1.0.14.2.20050215100243.02f5de40@127.0.0.1>,
 Graham Klyne  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
       settings.
]]
-- http://www.ietf.org/rfc/rfc3339.txt

Sorry for the confusion.  Let normal programming resume.

#g

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact