[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.