timezone in non-precise time types

The ability to add a timezone to time types other than dateTime is 
confusing at best, and especially for non-instance types like GDay, 
GMonth, etc. virtually impossible to use in a meaningful way. Either its 
meaning must be more clearly defined or (preferably) the timezone 
information should be removed altogether.

Even in dateTime there has been much confusion around timezones. A 
direct problem of the representation of timezone is the lack of ability 
to supply daylight savings information which can cause difficulty in 
recreating the exact language object from which the original time was 
derived. A solution would be to simply make dateTime require the time in 
UTC (which is the format almost every implementation I've seen writes in 
and the only truly interoperable solution). In essence timezone 
information could be removed completely from all types (dateTime is the 
arguable exception) without detriment to the functionality of those 
types currently supporting it (in fact, people may actually start to use 
them).

If the timezone were removed then the usefulness of single field types 
like GDay, GMonth and GYear becomes questionable. These can then be 
represented as integers. This is the way most people currently represent 
these types because of the confusion and lack of interoperability around 
them.

Received on Tuesday, 16 December 2003 05:38:01 UTC