RE: [ISO8601] Re: Dates-Timezones & eBusiness
- Although 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
> If I buy a ticket with a particular departure time and the conversionrules
> change after purchase, but the local time for departure under the newtime
> zone law doesn't change, storing as UTC will make the time incorrect,The departure time printed on the ticket, not being subject to data
interchange (between computers), is likely to be in local time. This is
true of both departure and arrival time currently, as I'm sure you're
When things change, things change, there's no getting around it. Trying
to pretend that it _didn't_ change simply because the effective
departure time _appears_ the same is incorrect. You'd darn well better
inform all your ticket holders about the change so they can plan
accordingly, they are likely to have connections outside the affected
locale and the arrival time at the destination will change as well.
- --- In ISO8601@yahoogroups.com, "Tex Texin" wrote:
> Although I agree in general, I also think that you are goingAll
> a bit too far with the statement that everything should be in
This thread is interesting because it seems to be placed within a
particular context - something to do with ticket sales etc.
I agree, too that the UTC format should not need changes or additions
to be used in any particular cotext which may well necessarily
require its own semantics to achieve a particular functionaity.
For my particular context (see www.tpeg.org) we have chosen to simply
use the YYYY-MM-DD T HH:MM:SS format of UTC within suitable
declarative messages such as Message Generation Time, Start Time,
Stop Time, Message Expiry Time - wherever in the world they are
generated; where "Time" in this context is a shorthand for the full
Date/Time UTC format as described.
Operating within Europe with two main time zones and co-ordinated
Summer Time changes we have experienced no particular problems (over
several years) in our context of exchanging Traffic and Travel
Information Messages. At least all time processing is using the same
format, regardless of functionality in our context of the
given "Time". (We have other Time types too complex to describe
- Why on earth would you use a site about conspiration theories and UFOs
for discussing an ISO standard? And what is wrong with this forum?
--- In ISO8601@yahoogroups.com, "Stephen GOULD" <sggould@o...> wrote:
> 13:12 Sat 07 Jan 2006 REF:AECSTFN2
> Y/R: ISO8601 Timezones
> TO: ISO8601 Special Interest Group cc ebXML Developers
> eBusiness Interests
> BBS SET UP FOR RESPONSES
> Hi - Thanks for the responses - your right we have to get away
> from manually typing dates in e-mails - 2 out of 2 wrong is a great
> way to start a discussion on an electronic standard date format !
> The reason why we have a start time/date and finish time/date is
> that, as e-mail is replacing written/typed correspondence, it
> can consume a lot of time reading and responding to e-mails
> particularly as part of Volunteer Special Interest Groups such as
> ISO 8601 and ebXML.
> Hence this is way at the 1996 OIC AGM Members unanimously voted
> to develop an eCredits process for Volunteer work
> The BBS has been set-up so you can post your response onto it to
> enable other interested parties join the discussion about ISO8601
> and Time Zones.
> It has been posted on godlikeproductions.com as
> "ISO8601 & Time Zones Work Group"
> Look forward to working with you to spread the word on how using the
> standard electronic date format ISO8601 can really benefit eBusiness
> and eCommunity operations
> Steve GOULD
> OIC XML & eCommerce Special Interest Group
> OPEN INTERCHANGE CONSORTIUM
> 13:36 S 2006/01/07 Syd 2065
> E: sggould@o...
> W: http://www.oic.org/z/XZIG/A/
- --- In ISO8601@yahoogroups.com, NGUYEN Ivy <nguyenivy@g...> wrote:
> I think you just indicate whatever default time you use (like 00:00),I don't understand this last comment. Obviously, any date and time you
> then use a timezone afterwards. I don't believe dates alone have
> timezone information in ISO 8601. It wouldn't make sense, unless some
> new provision is added like 'all dates without times that have
> timezone information, are to be treated as 00:00 if no time is
> It is true that giving a date without a timezone can cause ambiguity,
> as at least half the world is always a different date than stated. But
> on the flip-side, if no time within the date is stated at all, than
> how can we have timezone information? '2000-01-01 in New York
> (UTC-05)' means that 24-hour period lasting from 00:00--24:00 in New
> York (timezone). Doesn't reveal much more.
specify is a range, if you want to view it that way. If, as you say,
we can view "2000-01-01" is the range [2000-01-01 T00:00, 2000-01-01
T24:00), then the time "2001-01-01 T20" could also be seen as the
range [2001-01-01 T20:00, 2001-01-01 T21:00).
Any time we represent will be specified to some amount of precision.
Just providing the date is one level of precision. Specifying the hour
is a higher level of precision, and indicating minute and second give
even higher precision. Since the ISO standard doesn't say whether to
interpret a date as a time range or as a singular point in time, that
is up to the application as far as I am concerned. Why then should you
draw a line at which precision level time zones are used?
If I choose to view a date as a singular point in time (much as many
would view T20:01:02 as a singular point), then that moment will occur
at a different local time in different time zones. Obviously we could
specify at which second it occurs, as in "The Swedish new year occurs
on 2006-01-01 00:00:00+01:00 and the Chinese new year occurs on
2006-01-29 00:00:00+08:00", but it is much more convenient to say "The
Swedish new year occurs on 2006-01-01+01 and the Chinese new year
occurs on 2006-01-29+08".
Perhaps the issue at hand here boils down to what is the purpose of
introducing reduced precision into the ISO standard in the first place.
- First, read section 22.214.171.124; it starts with, "When the application
identifies the need for an expression only of a calendar date" ...
That is, the date and nothing more. It's a date, not a day.
> I don't understand this last comment. Obviously, any date and timeyou
> specify is a range, if you want to view it that way. If, as you say,Sure you can view it that way, but ISO8601 doesn't, because it would
introduce ambiguity, but of course "by agreement of the partners in
interchange" overrides pretty much everything.
> we can view "2000-01-01" is the range [2000-01-01 T00:00, 2000-01-01If you mean the range, then say the range. Remember, this standard is
> T24:00), then the time "2001-01-01 T20" could also be seen as the
> range [2001-01-01 T20:00, 2001-01-01 T21:00).
primarily for computers communicating, not humans. Certainly if I
were typing a date into an email I wouldn't bother with the whole
range, but when writing a program, I would tell _it_ to do so.
And of course you would use a properly formatted "interval" for that.
> Any time we represent will be specified to some amount of precision.And you can't remove the precision in between the date and timezone.
It would be like specifying a year and day-of-the-month with no month.
That would be "eviscerated precision".
> is up to the application as far as I am concerned. Why then shouldyou
> draw a line at which precision level time zones are used?Time zones are only allowed for times. That's why they're
called "time zones". (I want to add a "duh" to that.)
But seriously you could try 2006/01/14T--:--:--+08:00 which is the
closest you could come, but it's not allowed because:
a) Truncating the seconds field of a time is not allowed
b) Truncated times are not allowed to be combined with dates
> 2006-01-29 00:00:00+08:00", but it is much more convenient toConvenient for _humans_, computers don't care.
> Swedish new year occurs on 2006-01-01+01 and the Chinese new yearDo persons of chinese heritage who live in San Francisco celebrate
> occurs on 2006-01-29+08".
the Chinese New Year at that offset? (Recognizing, of course, that
San Franciscans do some strange things.)
Would you celebrate the Gregorian New Year in accordance with
Gregor's offset or your own?
> Perhaps the issue at hand here boils down to what is the purpose ofplace.
> introducing reduced precision into the ISO standard in the first
It's all reduced precision, even the standard recognizes that a
second is not the smallest unit of time. What constitutes the
smallest meaningful unit is application-specific.
However, the standard dictates that if time of day is specified then
it must be in hour-sized units at most.
> Why on earth would you use a site about conspiration theories and UFOsBecause of the black helicopters.
> for discussing an ISO standard?
> And what is wrong with this forum?Nothing wrong with this forum. It's the place to be.
> Operating within Europe with two main time zones and co-ordinatedYay! A happy customer. Go forth and spread the word!
> Summer Time changes we have experienced no particular problems (over
> several years) in our context of exchanging Traffic and Travel
> Information Messages. At least all time processing is using the same
Perhaps you could write up a small article that describes what sorts of
things you use timestamps for and how ISO8601 solved any problems or
concerns you had. It would make a good addition to the files section on
here I think.
What a surprise to see this mail, which I thought had been lost in
cyberspace, turn up 12 days later - it may have lost its impact in
the thread therefore... (Let's see if this one arrives any quicker?)
Firstly I need to say the URL I quoted requires "/old.htm" to be
added, if you really want to look into the TPEG Project work. But as
challenged I am more than happy, in the next few weeks, to write a
short article to show how we use ISO 8601.
--- In ISO8601@yahoogroups.com, "piebaldconsult"
> > Operating within Europe with two main time zones and co-ordinated
> > Summer Time changes we have experienced no particular problems
> > several years) in our context of exchanging Traffic and Travelsame
> > Information Messages. At least all time processing is using the
> Yay! A happy customer. Go forth and spread the word!
> Perhaps you could write up a small article that describes what
> things you use timestamps for and how ISO8601 solved any problemsor
> concerns you had. It would make a good addition to the filessection on
> here I think.