Re: data expression of date information

Al Gilman scripsit:

> 4. Warning: omitting localOffset is legitimate in planDateTime if a location
> is given in geographic terms.  This is the "when it's noon in Boston" usage
> as opposed to "17:00 UTC" or "12:00 -05" usage.  But I don't think that this
> needs to be anything more than a remark in defining how to express past events
> in EARL.

The point I was trying to make to Al (maybe a little confused by the
circumstances) was that date+offset is adequate for *past* times, but
inadequate for future ones.  If I make an appointment to meet you in Times
Square at midnight 2005-01-01, that is not equivalent to saying I'll meet
you at 2005-01-01 05:00 UTC.  The U.S. might change the time zone rules
between now and then -- unlikely but not impossible, given that it did
just that in 1974-75, extending daylight savings time for most of the year.

There is no resolution in principle for this, but using the historically
based time zone names of the ADO (GNU) time zone library, like
America/New_York, provides the best hope.  It is especially significant
that ADO divides time zones by country, since it is the country that
is responsible for assigning local times.  Thus, Europe/Paris currently
behaves just the same as Europe/Copenhagen, but it has not always been
so and may not be so in future.

See ftp://elsie.nci.nih.gov/pub for downloadable ADO time zone information.
The latest file is tzdata2002d.tar.gz

-- 
John Cowan                              <jcowan@reutershealth.com>
http://www.ccil.org/~cowan              http://www.reutershealth.com
Unified Gaelic in Cyrillic script!
        http://groups.yahoo.com/group/Celticonlang

Received on Thursday, 19 December 2002 11:14:22 UTC