RE: [COAS-List] UTC offset? string TimeStamp?

[Jay Brinton <brinton@adelphia.net>]

Larry's proposal makes sense to me.  If you have a satisfactory standard 
(particularly ISO), why not use it?  The efficiency of using a string over 
a struct is also a bonus.

-----Original Message-----
From:	David Forslund [SMTP:dwf@acl.lanl.gov]
Sent:	Friday, April 02, 1999 12:31 AM
To:	Larry Hamel
Cc:	coas@cs.fiu.edu; jeg@lanl.gov
Subject:	Re: [COAS-List] UTC offset? string TimeStamp?

I think you make some excellent points.  I'm not sure COAS needs its own
Time definition, either.  If you adopt the string format, though, I think 
it
means you need some other mechanism to handle the wild-carding and open
ended time intervals (such as a logical element) for TimeSpan.

Dave
Larry Hamel writes:
 > 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.