[COAS-List] UTC offset? string TimeStamp?

[Larry Hamel <larryh@medgrid.philips.com>]

y'all,

as i study time standards in relation to COAS, i'm coming full-circle back
to a UTC (GMT) offset rather than a timezone code, and questioning use of a
COAS-invented struct to represent time.  

explanations of the ISO 8601 date/time standard can be found at

http://www.cl.cam.ac.uk/~mgk25/iso-time.html
http://www.roguewave.com/products/resources/exchange/iso8601.html
http://www.hut.fi/u/jkorpela/iso8601.html
http://www.w3.org/TR/NOTE-datetime
http://www.lanl.gov/projects/ia/stds/ia830210.html

these point out (at bottom are excerpts) that there's no international
standard for timezones, and if there were, keeping up with international
legislation about timezones would be quite a challenge for such a standard.
this reference:

http://www.magnet.ch/serendipity/hermetic/cal_stud/newman.txt

mentions a IANA registry of timezone names, but the iana.com site has no
information about timezones that i can find.  keep in mind that if we
record a timezone instead of an offset to UTC, and subsequently the
definition of the timezone/daylight-saving changes, we would need a
historical table of timezone definitions to recapture the offset information.

furthermore, as i read more about ISO 8601 and see how we're trying to
accommodate  flexibility in a TimeStamp struct, i'm motivated to ask: why
is COAS inventing a new struct TimeStamp?  a string TimeStamp can flex
quite well when there are unknown parts of a time or date, and it can be
well-specified with constants 
for minimum 
(const string EARLIEST_TIME = "1582-10-15T00:00:00Z") 
and maximum 
(const string LATEST_TIME = "9999-12-31T23:59:59Z") times.  

the ISO 8601 format is human-readable for debugging, and there are existing
implementation libraries (like java.sql.Timestamp) that provide Calendaring
and comparison operations for it.

why not use ISO 8601, a formatted string, for the COAS TimeStamp?

larry

---------------
6.1. Problems Too Hard to Solve

     Since local timezone rules are set by local governments, the only
     authoratative reference for such rules is those governments, most
     of which do not currently provide their rules on line in a computer
     parsible format.  In addition, local timezones were historically
     set by cities and towns, so attempting to exhaustively enumerate
     all historical timezones for use in representing past dates is not
     practical.  Attempting to predict where new timezones will be
     created as a subset of the area covered by an old timezone is also
     a hopeless prospect.

-----------------------
Time Zone

<snip>

There exists no international standard that specifies abbreviations for
civil time zones like CET, EST, etc. and sometimes the same abbreviation is
even used for two very different time zones. In addition, politicians enjoy
modifying the rules for
civil time zones, especially for daylight saving times, every few years, so
the only really reliable way of describing a local time zone is to specify
numerically the difference of local time to UTC. Better use directly UTC as
your only time zone where this is possible and then you do not have to
worry about time zones and daylight saving time changes at all. 

More Information about Time Zones

Arthur David Olson and others maintain a database of all current and many
historic time zone changes and daylight saving time algorithms. It is
available via ftp from elsie.nci.nih.gov in the tzcode* and tzdata* files.
Most Unix time zone
handling implementations are based on this package. If you want to join the
tz mailing list, which is dedicated to discussions about time zones and
this software, please send a request for subscription to
tz-request@elsie.nci.nih.gov. You can read previous discussion there in the
tz archive.