1417RE: [ISO8601] Re: Dates-Timezones & eBusiness
- Jan 6, 2006Although I agree in general, I also think that you are going bit too far
with the statement that everything should be in UTC.
If dates are used in a hub for interchange, the date instance values may
need to persist for a long time.
(Essentially stored in the hub.)
However, the rules for conversion between UTC and local times are subject to
If a date-time really reflects a local time (e.g. the time of departure of a
plane) it can be better to represent the local time without the time zone
offset. The time zone offset would be determined at the point the date-time
is actually used.
Then if the rules for conversion to UTC change, the data is not corrupted.
As you know, there are examples of local (or federal) governments opting to
temporarily or permanently change the date for switching to daylight
If I buy a ticket with a particular departure time and the conversion rules
change after purchase, but the local time for departure under the new time
zone law doesn't change, storing as UTC will make the time incorrect, unless
there is a way to find all of the instances and reconvert them. That is not
There are cases where date value representation should reflect the semantics
of the date-time, ie whether it is a local time regardless of the relation
to UTC, or a particular instant in time, in which case it is accurately
represented by a UTC time, regardless of how it is called locally.
Internationalization Architect, Yahoo! Inc.
> -----Original Message-----
> From: ISO8601@yahoogroups.com
> [mailto:ISO8601@yahoogroups.com] On Behalf Of piebaldconsult
> Sent: Friday, January 06, 2006 7:02 PM
> To: ISO8601@yahoogroups.com
> Subject: [ISO8601] Re: Dates-Timezones & eBusiness
> Section 5.3.4 of ISO8601 (in the 2000 version) explains how
> to indicate
> your local offset from UTC, i.e. your time zone, so I have no
> idea why
> this thread was even started.
> And furthermore, data interchange should _not_ be made with local
> times, only with UTC. In this respect, ISO8601 already goes
> too far, it
> needn't even have section 5.3.4 to achieve its goals. Any
> perceived "problems" or "shortcomings" of ISO8601 are merely due to a
> lack of understanding by they who can't seem to grasp the concept. If
> you simply always use UTC in data interchange all the "problems" go
> Yahoo! Groups Links
- << Previous post in topic Next post in topic >>