I may have found a way to eliminate mm-dd-yyyy and AM/PM times from the
headers of e-mails. Although my computer was set to ISO 8601, my e-mail
headers were in English and used the US format .

This is what I did:

1. I had my computer set to Nederland when I bought it.
2. Now I set it to USA-English.
3. In this format I modified for my own use the decimal sign,  grouping of
numbers and system of measurement. Then, in order to get ISO time and dates,
I modified the corresponding US formats, and it seems to work.
So now, in order to avoid US formats in in my e-mail headers I am using
heavily modified USA-English settings.

Han Maenen said:

> I may have found a way to eliminate mm-dd-yyyy and AM/PM times from the
> headers of e-mails. Although my computer was set to ISO 8601, my e-mail
> headers were in English and used the US format .
>

Which headers are you referring to?

The Date: header is standardised, and must be in the form
  [Weekday,] dd Mmm yyyy hh:mm[:ss] timezone
since it's intended to be "read" by programs (mail transfer agents
and mail user agents) and not by people: your mail client should
reinterpret it when displaying the relevant information to you. It
does not contain mm-dd-yyyy date or AM/PM time.

The Received: headers are not withing your control at all, because
they're created by the various mail agents that handle the message on
its way between systems. However, they should be using the same form
of date as the Date: header (though failure to do so is less likely
to cause problems).

I can't think of any other (standard) headers that would usually
contain dates.

I am referring to headers that show in the body of the messages, things like
the one below: Original Messages.

----- Original Message -----
From: "Fred Bone" <fred.bone@...>
To: <ISO8601@yahoogroups.com>
Sent: Wednesday, 2002-06-05 12:32
Subject: Re: [ISO8601] Settings in e-mail headers

Before I made these changes, it would have looked like this:

----- Original Message -----
From: "Fred Bone" <fred.bone@...>
To: <ISO8601@yahoogroups.com>
Sent: Wednesday, June 6, 2002 12:32 PM
Subject: Re: [ISO8601] Settings in e-mail headers

Han






> Han Maenen said:
>
> > I may have found a way to eliminate mm-dd-yyyy and AM/PM times from the
> > headers of e-mails. Although my computer was set to ISO 8601, my e-mail
> > headers were in English and used the US format .
> >
>
> Which headers are you referring to?
>
> The Date: header is standardised, and must be in the form
>  [Weekday,] dd Mmm yyyy hh:mm[:ss] timezone
> since it's intended to be "read" by programs (mail transfer agents
> and mail user agents) and not by people: your mail client should
> reinterpret it when displaying the relevant information to you. It
> does not contain mm-dd-yyyy date or AM/PM time.
>
> The Received: headers are not withing your control at all, because
> they're created by the various mail agents that handle the message on
> its way between systems. However, they should be using the same form
> of date as the Date: header (though failure to do so is less likely
> to cause problems).
>
> I can't think of any other (standard) headers that would usually
> contain dates.
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>

Hi all,
A team under my leadership has been putting together an
implementation of ISO8601 for the Java programming language.

The JodaTime project seeks to provide a complete replacement for the
existing Date and Calendar utility classes provided by the language.
Both the existing classes are very weak, and neither handles ISO8601
well at all.

Details of the project, and the new 0.7 release can be found at:
Documentation:  http://joda.sourceforge.net/api/index.html
Description:  http://joda.sourceforge.net/dates.html
Download:  http://joda.sourceforge.net/source.html

I'm guessing that there are some programmers on this group. Maybe
you'd like to take a look and give some feedback, either here or to
scolebourne@.... Even non-programmers will probably
find the documentation fairly readable!!

Stephen

Doh, wrong link...here's the correct one:
Documentation:  http://joda.sourceforge.net/api-time/index.html
Description:  http://joda.sourceforge.net/dates.html
Download:  http://joda.sourceforge.net/source.html

Stephen

>Hi all,
>A team under my leadership has been putting together an
>implementation of ISO8601 for the Java programming language.
>
>The JodaTime project seeks to provide a complete replacement for the
>existing Date and Calendar utility classes provided by the language.
>Both the existing classes are very weak, and neither handles ISO8601
>well at all.
>
>Details of the project, and the new 0.7 release can be found at:
>Documentation:  http://joda.sourceforge.net/api/index.html
>Description:  http://joda.sourceforge.net/dates.html
>Download:  http://joda.sourceforge.net/source.html
>
>I'm guessing that there are some programmers on this group. Maybe
>you'd like to take a look and give some feedback, either here or to
>scolebourne@.... Even non-programmers will probably
>find the documentation fairly readable!!
>
>Stephen
>


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

Following is a reply I am posting to a list regarding satellite
observation which might be of interest to ISO 8601ers.  I'm a
bit surprised the subject hasn't been mentioned here before.

--------------------------------------------------------------------------
jcm@... wrote:
>
> This is a hot topic right now: the GPS community (at least I think
> they are the perpetrators) are trying to persuade IERS to abandon leap
> seconds entirely so that their software is easier.

My first thought was that the idea of dropping leap seconds was
potty but having read a bit about it and reflected on the requirements
and knowledge of different users I'm coming round to the view that
it might not be such a bad idea.

A Google search for "UTC" and "redefinition" showed up a good discussion
of who's behind this and why at:

   http://space.mit.edu/URSI/leapsecond.html

particularly:

   http://space.mit.edu/URSI/lsappendix3.html

As often happens with picky subjects like this, Markus Kuhn is a fount
of knowledge, see the references at the end of his <time.h> article:

   http://www.cl.cam.ac.uk/~mgk25/c-time/

paticularly:

   http://www.cl.cam.ac.uk/~mgk25/c-time/metrologia-leapsecond.pdf

for a very detailed discussion of the history of leap seconds and
a reasonable discussion of why they should be dumped.

It doesn't seem to be the "GPS community" as such who want this change
but rather the many people who want to synchronise computer networks to
better precision than a few seconds but with software which doesn't
spend all its time worrying about either leap seconds or the difference
between civil time (as typed in by the user/operator setting the
clock) and TAI.

> This would mean
> noticeable drifts of UTC relative to the sky on timescales of a decade
> or so, and make a lot of professional astronomy software seriously
> broken.

In most cases, only if it assumed that UT1 - UTC < 1 second (as it
appears that the format of some timesignals do) or that UT1 and UTC
are close enough not to matter.  There are no leap seconds due for
a while so there'll be plenty of time to fix this.

> The astronomy community are screaming and telling the nav
> people that if they don't like leap seconds they should just use
> a perfectly good preexisting timescale like TAI or TT, and don'tmess
> with our UTC.

I guess the question is: should the operation of UTC be determined
by the needs of the astronomers who understand things like the
difference between UT1 and UTC or by the needs of the rest of the
world who hardly care at all?

On the other hand - as computers get more connected (e.g., more
"always on" connections) protocols like NTP will be used more and
more to set and correct the computer clock so getting leap second,
(UTC - TAI) and even (UT1 - UTC) information will be automatic and
not bother the user anyway.

> Today is actually the deadline for users of UTC to
> send in their comments on the proposal: see the questionnaire at
> http://hpiers.obspm.fr/eop-pc/products/questionnaire-utc.txt
> and if you have strong opinions about leap seconds, send it in TODAY.
>  Would visual observers prefer to switch to something like TAI?

I think observers should continue to use UTC as it relates so
directly to civil time.  Analysts and prediction software should
ideally take leap seconds into account.  A good way would be to
use TAI consistently internally - that is, subtract the appropriate
UTC - TAI from received observations or elements and add back the new
appropriate offset to predictions or predicted elements.

This would mean that predications for a pass on January 1st after
a leap second at the end of the previous year would be correctly
calculated from observations taken over the previous few days -
whether or not the epoch of the elements used was before or after
the midnight at the start of that day.

Dropping leap seconds from UTC would eliminate the need for this
nonsense.

> Or do you like the fact that UTC directly relates hour angle to
> RA (admittedly only at equinox of date?). It'll be thousands of years
> before we start getting daylight at midnight due to lack of leap
> seconds, so it won't bother the average member of the public.
>  - Jonathan McDowell

The problem for software is the unpredictability of when leap seconds
will be added.
If they were added at predictable times, then software could easily
accomodate them.
We need to add one about every year and a half. I wonder if it wouldn't
be better to schedule them out a hundred years so most software could
take them into account and let the astronomical software that needs
accuracy greater than 1 second deal with the special cases of where
astronomical time is different from utc.

Today, if I want to validate time that a user enters, I cannot know
whether to reject a minute with 61 seconds or not because it might
potentially have had a leap second added.

tex

Ed Davies wrote:
>
> Following is a reply I am posting to a list regarding satellite
> observation which might be of interest to ISO 8601ers.  I'm a
> bit surprised the subject hasn't been mentioned here before.
>
> --------------------------------------------------------------------------
> jcm@... wrote:
> >
> > This is a hot topic right now: the GPS community (at least I think
> > they are the perpetrators) are trying to persuade IERS to abandon
> leap
> > seconds entirely so that their software is easier.
>
> My first thought was that the idea of dropping leap seconds was
> potty but having read a bit about it and reflected on the requirements
> and knowledge of different users I'm coming round to the view that
> it might not be such a bad idea.
>
> A Google search for "UTC" and "redefinition" showed up a good
> discussion
> of who's behind this and why at:
>
>   http://space.mit.edu/URSI/leapsecond.html
>
> particularly:
>
>   http://space.mit.edu/URSI/lsappendix3.html
>
> As often happens with picky subjects like this, Markus Kuhn is a fount
>
> of knowledge, see the references at the end of his <time.h> article:
>
>   http://www.cl.cam.ac.uk/~mgk25/c-time/
>
> paticularly:
>
>   http://www.cl.cam.ac.uk/~mgk25/c-time/metrologia-leapsecond.pdf
>
> for a very detailed discussion of the history of leap seconds and
> a reasonable discussion of why they should be dumped.
>
> It doesn't seem to be the "GPS community" as such who want this change
> but rather the many people who want to synchronise computer networks
> to
> better precision than a few seconds but with software which doesn't
> spend all its time worrying about either leap seconds or the
> difference
> between civil time (as typed in by the user/operator setting the
> clock) and TAI.
>
> > This would mean
> > noticeable drifts of UTC relative to the sky on timescales of a
> decade
> > or so, and make a lot of professional astronomy software seriously
> > broken.
>
> In most cases, only if it assumed that UT1 - UTC < 1 second (as it
> appears that the format of some timesignals do) or that UT1 and UTC
> are close enough not to matter.  There are no leap seconds due for
> a while so there'll be plenty of time to fix this.
>
> > The astronomy community are screaming and telling the nav
> > people that if they don't like leap seconds they should just use
> > a perfectly good preexisting timescale like TAI or TT, and don'tmess
> > with our UTC.
>
> I guess the question is: should the operation of UTC be determined
> by the needs of the astronomers who understand things like the
> difference between UT1 and UTC or by the needs of the rest of the
> world who hardly care at all?
>
> On the other hand - as computers get more connected (e.g., more
> "always on" connections) protocols like NTP will be used more and
> more to set and correct the computer clock so getting leap second,
> (UTC - TAI) and even (UT1 - UTC) information will be automatic and
> not bother the user anyway.
>
> > Today is actually the deadline for users of UTC to
> > send in their comments on the proposal: see the questionnaire at
> > http://hpiers.obspm.fr/eop-pc/products/questionnaire-utc.txt
> > and if you have strong opinions about leap seconds, send it in
> TODAY.
> >  Would visual observers prefer to switch to something like TAI?
>
> I think observers should continue to use UTC as it relates so
> directly to civil time.  Analysts and prediction software should
> ideally take leap seconds into account.  A good way would be to
> use TAI consistently internally - that is, subtract the appropriate
> UTC - TAI from received observations or elements and add back the new
> appropriate offset to predictions or predicted elements.
>
> This would mean that predications for a pass on January 1st after
> a leap second at the end of the previous year would be correctly
> calculated from observations taken over the previous few days -
> whether or not the epoch of the elements used was before or after
> the midnight at the start of that day.
>
> Dropping leap seconds from UTC would eliminate the need for this
> nonsense.
>
> > Or do you like the fact that UTC directly relates hour angle to
> > RA (admittedly only at equinox of date?). It'll be thousands of
> years
> > before we start getting daylight at midnight due to lack of leap
> > seconds, so it won't bother the average member of the public.
> >  - Jonathan McDowell
>
>                    Yahoo! Groups Sponsor
>                        ADVERTISEMENT
>                        [Click Here!]
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

--
-------------------------------------------------------------
Tex Texin   cell: +1 781 789 1898   mailto:Tex@...
Xen Master                          http://www.i18nGuy.com

XenCraft 	            http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------

http://www.kcl.ac.uk/kis/support/cit//staff/brian/caesar.html

Tex Texin said:

> The problem for software is the unpredictability of when leap seconds
> will be added.
> If they were added at predictable times, then software could easily
> accomodate them.
> We need to add one about every year and a half. I wonder if it wouldn't
> be better to schedule them out a hundred years so most software could
> take them into account and let the astronomical software that needs
> accuracy greater than 1 second deal with the special cases of where
> astronomical time is different from utc.
>

If it were possible to schedule them that far in advance, doubtless
either it would have been done or the definition of the second would
have been adjusted to eliminate the need.

The fact is that years are not all the same length, and the variation
is inherently unpredictable. Consequently the decision about leap
seconds is made some six months ahead. The last one was at the end of
December 1998, and we are currently experiencing the longest period
with no leap second since the concept was introduced.

Fred,

Possibly. Sometimes the solutions you get are a function of the
requirements you choose to satisfy.
So Perhaps.

Or perhaps the designers of the system are focused on the needs of those
(few?) that need that level of accuracy and not on the (large number of)
software programs that need predictability and so designed in more
precision than is needed (by most) at the cost of less than 6 months of
predictability.

I am not an expert on the subject and will not pretend to be. (But I'll
press on anyway! ;-) )

We do know that we need to make an adjustment every year and a half or
so. From 1972 to '99, there were 22 seconds added in the 27 year span.
So I wonder if we couldn't plan to add another 20 or so in the next
quarter century and then have a reckoning then. Over the course of the
25 years we might get a little more out of balance than 1 second but it
would average out over time. Meanwhile the number of users being allowed
to have minutes with 61 seconds will be held in check. (Although
realistically neither problem is that big a deal.)

Actually, I would settle for a 10 year plan, since most software has a
lifespan or at least an update cycle, less than that.
It seems that 6 months notice would have to be a design that didn't take
software needs into account.

(Please don't someone reply that web services will fix all of this
anyway. ;-) )
tex


Fred Bone wrote:
>
> Tex Texin said:
>
> > The problem for software is the unpredictability of when leap
> seconds
> > will be added.
> > If they were added at predictable times, then software could easily
> > accomodate them.
> > We need to add one about every year and a half. I wonder if it
> wouldn't
> > be better to schedule them out a hundred years so most software
> could
> > take them into account and let the astronomical software that needs
> > accuracy greater than 1 second deal with the special cases of where
> > astronomical time is different from utc.
> >
>
> If it were possible to schedule them that far in advance, doubtless
> either it would have been done or the definition of the second would
> have been adjusted to eliminate the need.
>
> The fact is that years are not all the same length, and the variation
> is inherently unpredictable. Consequently the decision about leap
> seconds is made some six months ahead. The last one was at the end of
> December 1998, and we are currently experiencing the longest period
> with no leap second since the concept was introduced.
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

--
-------------------------------------------------------------
Tex Texin   cell: +1 781 789 1898   mailto:Tex@...
Xen Master                          http://www.i18nGuy.com

XenCraft 	            http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------

Tex Texin wrote:
>
> Fred,
>
> Possibly. Sometimes the solutions you get are a function of the
> requirements you choose to satisfy.
> So Perhaps.

????

>
> Or perhaps the designers of the system are focused on the needs of those
> (few?) that need that level of accuracy and not on the (large number of)
> software programs that need predictability and so designed in more
> precision than is needed (by most) at the cost of less than 6 months of
> predictability.

I agree - my comments below are an expansion of this point.

>
> I am not an expert on the subject and will not pretend to be. (But I'll
> press on anyway! ;-) )

That's the spirit... :-)

>
> We do know that we need to make an adjustment every year and a half or
> so. From 1972 to '99, there were 22 seconds added in the 27 year span.
> So I wonder if we couldn't plan to add another 20 or so in the next
> quarter century and then have a reckoning then. Over the course of the
> 25 years we might get a little more out of balance than 1 second but it
> would average out over time.

This averaging out is a key point.  As I understand it - the
variation in the Earth's rotation consists of a fairly predictable
long term trend with shorter term (year to decade duration)
fluctuations on top.  Recently the short term fluctations have,
presumably, tended to cancel out the long term trend so we've not
had any leap seconds for a while.

If the |UT1 - UTC| < 0.9s constraint were to be relaxed somewhat
(I leave it to the experts to work out by how much) then presumably
we could schedule leap seconds a much longer way out to take account
of just the long term trend.

> Meanwhile the number of users being allowed
> to have minutes with 61 seconds will be held in check. (Although
> realistically neither problem is that big a deal.)

I don't think the concerns are so much with respect to user
interface issues such as this.  They're more to do with systems,
particularly those in networks, not working out time differences
properly.  E.g., two machines are synchronised and sending time-
stamped messages to one another.  One implements leap seconds
properly and counts 23:59:59, 23:59:60, 00:00:00 while the other
counts 23:59:59, 00:00:00, 00:00:01.  Suddenly one receives
timestamps from the "future".

Bearing in mind that national banks managed to get their ATM
machines not to work properly on February 29th not all that
many years ago, what are the hopes that relatively subtle
problems with unpredicatable and not so well known leap
seconds will be avoided.

E.g., GLONASS, the Russian sat nav system equivalent to GPS
needs to drop out for a short while to reset its clocks every
leap second as it uses UTC, unlike GPS which uses its own
time base.

>
> Actually, I would settle for a 10 year plan, since most software has a
> lifespan or at least an update cycle, less than that.

As long as time convertions and arithmetic are done by the OS or a
suitable shared library it would be fairly easy for this to be
updated as required.  None of the operating systems I run are older
than 10 years but quite a few little programs are.  If lots of
software distributions (OS and application program) installed the
latest version of the "time library" (being careful not to overwrite
more recent versions of course) then the problem would go away.

> ...
>
> (Please don't someone reply that web services will fix all of this
> anyway. ;-) )

Well, having the IERS bulletins available in a convenient format
(e.g., one based on XML) at a well known address might help - e.g.,
so that the "time library" mentioned above could update itself
every month or so.

Ed.

Fred Bone wrote:
>
> Tex Texin said:
>
> > The problem for software is the unpredictability of when leap seconds
> > will be added.
> > If they were added at predictable times, then software could easily
> > accomodate them.
> > We need to add one about every year and a half. I wonder if it wouldn't
> > be better to schedule them out a hundred years so most software could
> > take them into account and let the astronomical software that needs
> > accuracy greater than 1 second deal with the special cases of where
> > astronomical time is different from utc.
> >
>
> If it were possible to schedule them that far in advance, doubtless
> either it would have been done or the definition of the second would
> have been adjusted to eliminate the need.

Adjusting the definition of the second would:

a) be a really big deal because of the knock-on effect on all the
    other SI units and derived standards and

b) not solve the problem in the long term anyway because the
    variation in day length contains a trend towards longer days (as
    well as short term unpredicatable fluctuations).

The reason we have had positive leap seconds but no negative leap
seconds is that, on average, days are now a few milliseconds longer
than they were when the measurements were made on which the original
definition of the second was made (I think I've seen both 1870 and
1820 quoted as the date on which the Earth's rotation period was
actually 86400.000 seconds).  This slowing down is caused primarily
by the dissipation of energy caused by tides.

> The fact is that years are not all the same length, and the variation
> is inherently unpredictable.

Leap seconds are more to do with variation in day length than year
length, i.e., they relate to variation in the rotation of the Earth
around its own axis, not round the Sun.

> Consequently the decision about leap
> seconds is made some six months ahead. The last one was at the end of
> December 1998, and we are currently experiencing the longest period
> with no leap second since the concept was introduced.
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[2002-Jul-03]


I have recently started a discussion in the HTML forum located at:

  <http://www.webmasterworld.com/forum21/2692.htm#msg1>.


One or two people in this ISO 8601 group may also wish to join in
at some stage. You will need to 'join' with a new User Name and a
Password if you wish to add any replies. The forum has open pages
for reading, but has closed membership for posting messages.



Cheers,

Ian.


<mail://g1smd@amsat.org>

<http://www.qsl.net/g1smd/>
<http://home.freeuk.net/g1smd/>
<http://ourworld.compuserve.com/homepages/dstrange/y2k.htm>
<http://dmoz.org/Science/Reference/Standards/Individual_Standards/ISO_8601/>

<ftp://ftp.funet.fi/pub/ham/misc/g1smd.zip>
<ftp://ftp.qsl.net/pub/g1smd/>


[2002-07-03]

.end

Hello everybody!

I have done a Flash ISO8601 date/time format (.fla file)
available at:

http://www.flashkit.com/movies/Utilities/Time/ISO8601D-John_Wal-
7259/index.php


regards
john


________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag

Instead of having lots of people thinking of time (in particular
seconds) in different ways would it not be easier to define
different meanings for the word second (and where accuracy is
important specify which meaning is being used).  For instance
defining an aboslute second, c-related (i.e. relative to speed of
light) second, sloar second, sidereal second, etc to keep everyone
happy.


Just an idea,
Joe Blakesley

At 21:37 2002-07-04 -0000, you wrote:
>Instead of having lots of people thinking of time (in particular
>seconds) in different ways would it not be easier to define
>different meanings for the word second (and where accuracy is
>important specify which meaning is being used).  For instance
>defining an aboslute second, c-related (i.e. relative to speed of
>light) second, sloar second, sidereal second, etc to keep everyone
>happy.
>
>
>Just an idea,
>Joe Blakesley

An excellent idea Joe. I've been using one of my own for years.

It's called 'Justa second' Very handy!

Arthur A. Lawrance.

--
In a networked world without fences and borders,
who needs Windows and Gates?

  <arthur@...>



.end

Hi,
As part of the www.joda.org implementation of ISO dates, I have been looking
at how to add support for TimeZones to the ISO standard. The standard only
permits a Z, +HHMM, -HHMM, +HH:MM, -HH:MM as timezones.

This is fine for expressing time from UTC, however there is also the
timezone name, such as 'Europe/London' or 'America/Vancouver'. This name
allows access to the daylight savings information and thus is a valid part
of a full time implementation.

My question is, does anyone know if there ever been any thought of changing
the ISO standard to allow for timezone names? At the moment I will probably
just add it to the formatted output at the end, but thats not ideal.

Stephen

On 2002-Jul-09 Stephen Colebourne wrote(>):


[2002-Jul-10]


> As part of the www.joda.org implementation of ISO dates, I have
> been looking at how to add support for TimeZones to the ISO
> standard. The standard only permits a Z, +HHMM, -HHMM, +HH:MM,
> -HH:MM as timezones.

That is correct. ISO 8601 is for Numeric formats, which is why
it also does not support the month in words or as an abbreviation.

It also supports +HH:MM rather than just +HH because there are a
fair number of time zones that are 15, 30 or 45 minutes away from
being a whole multiple of hours offset from UTC.



> This is fine for expressing time from UTC, however there is also
> the timezone name, such as 'Europe/London' or 'America/Vancouver'.
> This name allows access to the daylight savings information and
> thus is a valid part of a full time implementation.

These names come from ISO 9945, and are for an entirely different
application altogether. These names give no indication of whether
Daylight Savings Time is in effect or not. These names cannot be
used to specify times in the future, because the actual UTC offset
may be changed at any time for political and/or other reasons in
any of these regions, and without prior notice. There is no agreed
standard or treaty for these things. There is also no agreed date
for start and end of Daylight Savings Time for more that one or two
years into the future, and the rules are subject to change at any
time, and have done so quite frequently in recent history.

This has been considered before:
<http://serendipity.magnet.ch/hermetic/cal_stud/newman.htm>

then rejected as shown by:
<http://community.roxen.com/developers/idocs/drafts/draft-ietf-impp-datetime
-05.html>.



> My question is, does anyone know if there ever been any thought
> of changing the ISO standard to allow for timezone names? At the
> moment I will probably just add it to the formatted output at the
> end, but that's not ideal.

Time zone names are very uneccessary in the standard. The standard
deals only with fully numeric formats. Nothing is both as compact,
and as obvious, as a format like  +0200 or -0500 . This also cannot
be altered by political decisions, so  2002-07-09 22:00:00 +02:00
will always mean the exact same single time instant, whereas the
date/time  2002-07-09 15:00:00 US/New_York, may, or may not, be the
same instant in time, depending on whether Daylight Savings Time
is, or isn't, in force; and exactly what time zone New York belonged
to on that date, and at that time. There is no official list of who
uses what zone and when it has been used, nor is there anyone who is
*officially* maintaining such information.


In most cases it is far better to convert all information to UTC
(or Z) and transmit that. Local zones can confuse:

     2002-07-10 09:00 Asia/Japan  is actually one hour BEFORE
     2002-07-09 21:00 US/New_York (NY is on DST on this date)

as you can see from:

     2002-07-10 09:00 Asia/Japan  = 2002-07-10 00:00 UTC
     2002-07-09 21:00 US/New_York = 2002-07-10 01:00 UTC.

If DST were not in force in the US on that date, there would be a
two hour gap. I assumed that Japan does not use Daylight Savings
Time at all. In places where DST is used, then please note that it
operates in antiphase in the Northen and Southern hemispheres, and
that countries near the Equator do not use it at all. It is also
important to note that different countries make the change on
different dates. This makes it a very complex area of study, and
therefore extremely difficult to maintain a working system.


Most people already know their offset from UTC, so I feel that it
is best to work solely in that time zone.



Cheers,

Ian.


<mail://g1smd@amsat.org>

<http://www.qsl.net/g1smd/>
<http://home.freeuk.net/g1smd/>
<http://ourworld.compuserve.com/homepages/dstrange/y2k.htm>
<http://dmoz.org/Science/Reference/Standards/Individual_Standards/ISO_8601/>

<ftp://ftp.funet.fi/pub/ham/misc/g1smd.zip>
<ftp://ftp.qsl.net/pub/g1smd/>


[2002-07-10]

.end

[2002-Jul-10]


I have recently started a discussion in the HTML forum located at:

  <http://www.webmasterworld.com/forum21/2692.htm#msg1>.

I am still waiting for people here to join in with that discussion.


You will need to 'join' with a new User Name and a Password if you
wish to add any replies. The forum has open pages for reading, but
has closed membership for posting messages.



Cheers,

Ian.


<mail://g1smd@amsat.org>

<http://www.qsl.net/g1smd/>
<http://home.freeuk.net/g1smd/>
<http://ourworld.compuserve.com/homepages/dstrange/y2k.htm>
<http://dmoz.org/Science/Reference/Standards/Individual_Standards/ISO_8601/>

<ftp://ftp.funet.fi/pub/ham/misc/g1smd.zip>
<ftp://ftp.qsl.net/pub/g1smd/>


[2002-07-10]

.end

At 2002-07-09 23:16 +0100, Stephen Colebourne wrote:
>This is fine for expressing time from UTC, however there is also the
>timezone name, such as 'Europe/London' or 'America/Vancouver'. This
>name allows access to the daylight savings information and thus is a
>valid part of a full time implementation.

The timezone name has a different purpose.  It serves as an input
to a date generator, typically via an environment variable.  The
output should still express offset in a numeric manner.

I do agree that these names improve on the three letter time zone
codes which were ambiguous because separate regions use some common
codes.   However they are still ambiguous during the transitions to
and from daylight savings time.  ISO offsets do not have that problem.

--
Pete Forman                -./\.-  Disclaimer: This post is originated
WesternGeco                  -./\.-   by myself and does not represent
pete.forman@...    -./\.-   opinion of Schlumberger, Baker
http://petef.port5.com           -./\.-   Hughes or their divisions.

2002-Jul-09 Stephen Colebourne wrote(>):
> As part of the www.joda.org implementation of ISO dates, I have
> been looking at how to add support for TimeZones to the ISO
> standard. The standard only permits a Z, +HHMM, -HHMM, +HH:MM,
> -HH:MM as timezones.
> ...
> This is fine for expressing time from UTC, however there is also
> the timezone name, such as 'Europe/London' or 'America/Vancouver'.
> This name allows access to the daylight savings information and
> thus is a valid part of a full time implementation.

2002-07-10T02:24 g1smd@... replied (#):
# These names come from ISO 9945, and are for an entirely different
# application altogether. These names give no indication of whether
# Daylight Savings Time is in effect or not.

I take your word for this.

# These names cannot be used to specify times in the future, because
# the actual UTC offset may be changed at any time for political and/
# or other reasons in any of these regions, and without prior notice.

Sorry, but this can't be right.  Just because you don't know the
future offset of a timezone from UTC doesn't mean you can't use
it to specify times in the future.  For example, I can schedule
a regular meeting at 16:00 (London time) on the first Monday of
each month as far ahead as I like.  OK, the time of the meeting
expressed in UTC might change if the politicians muck with the
start or end (or existence) of daylight saving time but the
actual meeting time is still well specified.

Later in the same message, g1smd@... wrote (#):
# There is no official list of who
# uses what zone and when it has been used, nor is there anyone who is
# *officially* maintaining such information.

Maybe there should be.

A uniform source of information on the predicted and (reasonably
recent) historical offsets of various daylight saving times from
UTC, UTC - TAI, sightings of the new moon in Mecca, etc, would make
writing accurate and hassle free date/time packages much easier.
(See comments in following message).

# In most cases it is far better to convert all information to UTC
# (or Z) and transmit that.

I agree, with the emphasis on *most*.  In a few cases you really
want to use the local time zone without necessarily knowing its
relevant offset from UTC (like my regular meeting example).

A complete date/time handling package should be able to deal with
this properly.  Meeting participants who will join in from their
desks in Vancouver should be able to see their local time in their
diary.  According to my desk diary, the UK went to DST on Sunday
2002-03-31 whereas the US and Canada went a week later on Sunday
2002-04-07:

Europe/London      UTC                  America/Vancouver
2002-03-04 16:00   2002-03-04 16:00     2002-03-04 08:00
2002-04-01 16:00   2002-04-01 15:00     2002-04-01 07:00
2002-05-06 16:00   2002-05-06 15:00     2002-05-06 08:00

Sounds like a really good April fool joke to make the North
Americans get up an hour early only to find the meeting's on
Tuesday because it's Easter Monday :-).

More seriously, this illustrates that there are good reasons
to use local time - even in interchange data, like when the
deatils of this repeated meeting are transmitted from the
diary system of the convener in London and that of the
participants in Vancouver.  However, the question is, should
this ever get into ISO 8601 or should it be placed at a higher
level?

My feeling is that there is already enough "junk" in 8601,
particularly the repeating events stuff and so on and that
any further application specific extensions like this might
be better put in another standard which references 8601
for the basic date/time representation (although I actually
think that local time zone representation is a better
candidate for inclusion than the repeating events stuff -
but that's already there).

Ed.

Following on from the comments on local timezones and the recent
thread about leap seconds I've been thinking about how a "central"
source of information about time offsets could be organized.

The obvious solution would be to have a web site somewhere which
contained XML documents with the information.  Different authorties
and sources could feed data there for distribution.  However,
the site would need quite a lot of management and would be quite
busy - even with the caching the web generally provides.

A less obvious idea would be to use the DNS.  Normally this is
used to map between domain names and internet addresses but
actually it is quite general and can manage multiple such
hierarchical mappings.  It is really good at allowing management
of different parts of the hierachy to be delegated to different
authorities (in this case, somebody in each country for DST
rules, the IERS or US Naval Observatory for UTC - TAI and/or
UT1 - UTC, the authorities in Mecca for the starts of the Islamic
months (if they'll deal with this instrument of the devil :-)).

The DNS is also really good at distributing information with a
known lifetime and keeping track of what is an authoritative
copy and what is just cached and so on.  Also, DNS lookups can
be quite lightweight - just a single UDP datagram in each
direction for short information.

I've read a bit about how the DNS works but that was a while
ago and I have no practical experience.  Anybody who has have
any comments?

Ed.

It would be big help for my application, if ISO would standardize the time
zone codes in the half dozen countries that have multiple time zones,
considering the European Union acts like a country since they all have the
same daylight saving rules.

It would help me if the time zone codes were standard even if they were only
unique within server domain code;  the ISO two letter code for country.

In the US, Canada and Australia I need the state code for precise rules  Some
states or territories do not have daylight saving in these countries.
Indiana mucks it up with three small areas that do have daylight saving time.
  I would be happy with standardized codes within country.  Unique within
North America would be nice but not necessary.

Have AST for Atlantic Stand Time and Alaska Standard Time and therefore the
later often is HST (Hawaii/Alaska Standard Time).

The standard for timezone should be the +/-HHMM that is in the
standard. If you want to use names for your personal use go ahead,
you can use your own names.

And don't forget that daylight savings time is a bad thing and should
be abolished.

Thanks for the interesting answers so far. Let me explain a little further.
What I am struggling with most is that the ISO standard includes an optional
time zone (Z/HHMM). Why is this there at all?

I am viewing 'time' as consisting of two parts:
The time in UTC
The timezone, a geographic variance to local time from UTC, expressed as a
name

The Z/HHMM part is incomplete data, in that it doesn't give me enough data
to fully rebuild the timezone. To retrieve the full time you need UTC time
plus the timezone name. The Z/HHMM concept just gives an alternative way of
stating the UTC time. It does not tell you the timezone, thus why include it
at all?

So why do I care? Well the applications that I work with need to be able to
take a time, store it as a String, and then retrieve it back again without
looosing _any_ information. I can only achieve this by modifying the
standard.

From: "Ed Davies" <edavies@...>
> However, the question is, should
> this ever get into ISO 8601 or should it be placed at a higher
> level?

Maybe this is in fact the question that I'm struggling with - thus my full
time format is something built on ISO8601, rather than being purely ISO.

Stephen

On 2002-Jul-10 Ed Davies wrote(>):


[2002-Jul-12]


># These names come from ISO 9945, and are for an entirely different
># application altogether. These names give no indication of whether
># Daylight Savings Time is in effect or not.

> I take your word for this.

This is referred to in those Chris Newman documents that I mentioned
earlier. I also gave the URLs for these in my earlier posting.



># These names cannot be used to specify times in the future, because
># the actual UTC offset may be changed at any time for political and/
># or other reasons in any of these regions, and without prior notice.

> Sorry, but this can't be right.  Just because you don't know the
> future offset of a timezone from UTC doesn't mean you can't use
> it to specify times in the future.  For example, I can schedule
> a regular meeting at 16:00 (London time) on the first Monday of
> each month as far ahead as I like.  OK, the time of the meeting
> expressed in UTC might change if the politicians muck with the
> start or end (or existence) of daylight saving time but the
> actual meeting time is still well specified.

There are still a few special cases where this isn't true. Humans
can probably understand what is happening, but it is machine-
generated events that will always be a big problem, if that
machine is in a different zone it may misinterpret the actual
time of the event.

Additionally, anything that is dealing with a duration will fail
if someone changes the UTC zone offset of that local time while
that duration is in progress (for example a change over to/from
DST). Durations are one of the problems that were highlighted in
recend 'Leap Second' discussions. Some systems are not tolerant
of an extra second. Here we could be adding in, or losing, a whole
hour!

There is another problem: example:  2004-03-28 02:30 Europe/London.
Ooops - this doesn't exist. This is (probably) the day that clocks
advance an hour (from 02:00 to 03:00) for the start of British
Summer Time. Either your event will not happen, it will be missed,
or it will trigger 30 minutes early, when 01:59:59 changes to
02:00:00 and is automatically corrected to 03:00:00.

It is also a problem if systems interchange data, and something
is supposed to happen before something else. If the two systems
are on two different time zones then it is vital that they each
are absolutely sure of their UTC offset at all times.



># There is no official list of who
># uses what zone and when it has been used, nor is there anyone
># who is *officially* maintaining such information.

> Maybe there should be.

Requires lots of International Treaties and so on. It'll never happen.
Time Zones are *political* and subject to change. Certain shades of
country would never participate in such a scheme. Stating the UTC
offset numerically can never fail: it's now  01:30 +0100  here.
It's British Summer Time, but the fact is... it's irrelevant. If you
are in a place that is 5 hours behind UTC, then think back to what
you were doing on  2002-07-11 19:30 -0500  and you were doing that
while I was typing this.



># In most cases it is far better to convert all information to UTC
># (or Z) and transmit that.

> I agree, with the emphasis on *most*. In a few cases you really
> want to use the local time zone without necessarily knowing its
> relevant offset from UTC (like my regular meeting example).

These would probably be non-computer applications, otherwise if
your personal organiser doesn't know what zone it is in, then
it may warn you that your meeting is due sometime after you were
meant to be there. It's not such a problem when it is a stand-alone
unit (as long as you alter the internal clock of the unit to show
time on screen in the zone that you are going to be using it); the
majority of the problems occur when it interfaces to other software
on remote systems that are possibly using a different time zone.

However, it is then possible that you might be a globe-trotting
business person. You could schedule a meeting in New York for
Monday 15:00 (New York Local Time), and then another in Sydney,
Australia for Tuesday 10:00 (Australian Local Time) and only later
realise you left yourself only THREE hours for travelling. It's an
extreme example, but I hope you see my point. Unqualified Local
Time is fraught with dangers.



> A complete date/time handling package should be able to deal with
> this properly.  Meeting participants who will join in from their
> desks in Vancouver should be able to see their local time in their
> diary.  According to my desk diary, the UK went to DST on Sunday
> 2002-03-31 whereas the US and Canada went a week later on Sunday
> 2002-04-07:

Something, somewhere, has to be able to know what time zone offset
from UTC is in force in each locality on every date; as well as
knowing the start and end dates for DST a very long way into the
future, otherwise people will be out of sync.

People in Britain have been caught out by this before. The UK uses
DST, and so does mainland Europe. It always used to be that all
countries moved from Standard Time to DST at the end of March. So
in Winter, Spring, and Summer, UK citizens visiting countries in
Continental Europe would have to advance their watches by one hour
as they crossed the Channel. However, Europe always finished DST at
the end of September, while the UK continued with DST until the end
of October. This meant that for several weeks the same time was in
force all across the UK and mainland Europe -  there was no need to
alter watches and clocks while crossing the Channel. At the end of
October the UK reverted to Standard Time and the one hour difference
returned. Many people used to change their watch during this month
and then find that it hadn't been necessary.



> Europe/London      UTC                  America/Vancouver
> 2002-03-04 16:00   2002-03-04 16:00     2002-03-04 08:00
> 2002-04-01 16:00   2002-04-01 15:00     2002-04-01 07:00
> 2002-05-06 16:00   2002-05-06 15:00     2002-05-06 08:00

It would have helped my understanding more if you had placed the US
on the left, the UK on the right, and kept the UTC time zone as the
constant. I think I understand you, but it could have been clearer.



> Sounds like a really good April fool joke to make the North
> Americans get up an hour early only to find the meeting's on
> Tuesday because it's Easter Monday :-).

Ah, Public Holidays are an absolute minefield. More so than time
zones. Don't get me started.



> More seriously, this illustrates that there are good reasons
> to use local time - even in interchange data, like when the
> details of this repeated meeting are transmitted from the
> diary system of the convener in London and that of the
> participants in Vancouver.  However, the question is, should
> this ever get into ISO 8601 or should it be placed at a higher
> level?

Any use of Local Time must always be clarified with the UTC offset
used, if you are transmitting that data to someone who may be in
a different zone, otherwise people may end up staring at blank
screens 'cus the other country has changed their offset due to DST
or other political reasons.



> My feeling is that there is already enough "junk" in 8601,
> particularly the repeating events stuff and so on and that
> any further application specific extensions like this might
> be better put in another standard which references 8601
> for the basic date/time representation (although I actually
> think that local time zone representation is a better
> candidate for inclusion than the repeating events stuff -
> but that's already there).

I feel that ISO 8601 is already adequate for Time Zones:

   2002-06-20  20:00:00  Z
   2002-06-20  20:00:00  +0000
   2002-06-20  15:00:00  -0500
   2002-06-21  06:00:00  +1000   are all equivalent.



Cheers,

Ian.


<mail://g1smd@amsat.org>

<http://www.qsl.net/g1smd/>
<http://home.freeuk.net/g1smd/>
<http://ourworld.compuserve.com/homepages/dstrange/y2k.htm>
<http://dmoz.org/Science/Reference/Standards/Individual_Standards/ISO_8601/>

<ftp://ftp.funet.fi/pub/ham/misc/g1smd.zip>
<ftp://ftp.qsl.net/pub/g1smd/>


[2002-07-12]

.end

On 2002-Jul-10 hjwoudenberg wrote(>):


[2002-Jul-12]


> It would be big help for my application, if ISO would standardize
> the time zone codes in the half dozen countries that have multiple
> time zones, considering the European Union acts like a country
> since they all have the same daylight saving rules.

This won't be true when the Eastern European states, or Finland,
or Turkey join the EC. What then? You cannot join all together
under one zone. It is also possible that time zone boundaries will
change again in the future for political reasons. The UK uses a
different zone to mainland Europe, so you are not correct.

Something like   1958-06-20 20:00 Europe/Prague  is VERY unclear
if comparing the data with that from other zones, or measuring a
duration. You may not know the Standard UTC offset, or whether
that area was observing DST at that time, or the dates that DST
begun and ended that year. The Date  1958-06-20  22:00  +02:00
is absolutely complete. This means it is 10pm Local Time at a
place that is exactly 2 hours ahead of UTC, in other words this
is the same as 20:00 UTC.

I'm not sure what you mean by 'standardise the codes'. Are you
referring to EST (Eastern Standard Time) etc. If so, then ISO do
not have any standards for these, as historically US states have
joined and left time zones on a random political basis. In some
states there are some counties that observe DST while others in
the same state do not. Only formats like '-0500' tell you exactly
what the offset is. A zone like EST or US/New York needs a list
of all the changes in meaning that have occurred over the years
to be carried with it, otherwise you may misread the meaning.
ISO 8601 only deals with numerical representations for time zone
information.



> It would help me if the time zone codes were standard even if
> they were only unique within server domain code;  the ISO two
> letter code for country.

The trouble is, you would have to have tables of information to look
up what the codes mean, which dates they applied, and whether DST
was being used at that time or not. I have no idea how you would try
to cater for special cases of Double Daylight Savings Time, or places
that decide on occasional years not to use DST. Numerical offsets are
clear, unambiguous and require no further clarification. I don't see
any problem with them.



> In the US, Canada and Australia I need the state code for precise
> rules. Some states or territories do not have daylight saving in
> these countries. Indiana mucks it up with three small areas that
> do have daylight saving time. I would be happy with standardized
> codes within country.  Unique within North America would be nice
> but not necessary.

These rules may be true today, but a political change will happen
sooner or later to change whatever is documented. What then? All
your software will be broken.



> Have AST for Atlantic Stand Time and Alaska Standard Time and
> therefore the later often is HST (Hawaii/Alaska Standard Time).

This has all been discussed before (many times) in the various
C programming language, POSIX, and SQL newsgroups (among others)
and via various list-servers. Archives for some of these can be
found on the web, and via <http://groups.google.com>.



Cheers,

Ian.


<mail://g1smd@amsat.org>

<http://www.qsl.net/g1smd/>
<http://home.freeuk.net/g1smd/>
<http://ourworld.compuserve.com/homepages/dstrange/y2k.htm>
<http://dmoz.org/Science/Reference/Standards/Individual_Standards/ISO_8601/>

<ftp://ftp.funet.fi/pub/ham/misc/g1smd.zip>
<ftp://ftp.qsl.net/pub/g1smd/>


[2002-07-12]

.end

On 2002-Jul-11 Stephen Colebourne wrote(>):


[2002-Jul-12]


> Thanks for the interesting answers so far. Let me explain a little
> further. What I am struggling with most is that the ISO standard
> includes an optional time zone (Z/HHMM). Why is this there at all?

This is why:
  2002-06-20 20:00:00        is a local time at an unknown location.
  2002-06-20 20:00:00 Z      is the date/time in UTC.
  2002-06-20 20:00:00 +02:00 is a local time at a place that is
  two hours ahead of UTC, hence the same as 18:00:00 UTC.



> I am viewing 'time' as consisting of two parts:
> The time in UTC
> The timezone, a geographic variance to local time from UTC,
> expressed as a name

Your second sentence here, makes no sense at all. I'm not sure
what you meant to say. A time zone isn't a variation to a local
time, it is a statement of how much that zone is offset from
some standard, non-changing, zone. The base zone is UTC, which
was known as GMT before 1971. For information about the change
do a search on Google. There are hundreds of places that explain
it. ISO 8601 does not use time zone names because they do not
convey any numerical meaning.

The ISO 8601 standard allows you to state a time in either UTC,
or as a local time but including the offset from UTC so that
interested parties can convert that time back to a UTC time.

2002-06-21 09:00 +1000 is an hour before 2002-06-20 19:00 -0500.

There is a minor difference between Z, +0000, and -0000. This is
also discussed in the Chris Newman stuff that I referenced earlier.



> The Z/HHMM part is incomplete data, in that it doesn't give me
> enough data to fully rebuild the timezone. To retrieve the full
> time you need UTC time plus the timezone name. The Z/HHMM concept
> just gives an alternative way of stating the UTC time. It does
> not tell you the timezone, thus why include it at all?

The +HHMM *IS* complete data. I'm not sure what you mean when you
say 'it does not let me rebuild the time zone'. You should forget
things like EST and JST if that is what you are trying to recreate.
There are too many problems with that sort of notation. The +HH:MM
is not just restating UTC time, it is stating a Local Time and
including the amount of the UTC offset. EST is 5 hours behind UTC
and EDT is 4 hours behind UTC, but that isn't obvious from the name.
What is the offset for JST, and just what is JST? If I meant Japan,
then the answer would be +1000. The ISO method is to drop references
like JST and just write the +1000 instead. If +0200 isn't a TimeZone
then just what is it?  2002-06-20 18:00 -05:00 is 18:00 Local Time
at a place that is 5 hours behind UTC.



> So why do I care? Well the applications that I work with need to be
> able to take a time, store it as a String, and then retrieve it back
> again without losing _any_ information. I can only achieve this by
> modifying the standard.

You don't have to modify anything. Please reread the standard. Either,
store all your data as local-time-with-UTC-offset, and then serve it
back up the same way. Else, convert the dates and times to UTC, store
the UTC version of the date and time along with a note of the offset
for that user. This has an advantage that you can serve data to all
users in their own local time, but can store it all in one zone (such
as UTC) which makes it very easy to sort all of the data into its true
temporal order.



Cheers,

Ian.


<mail://g1smd@amsat.org>

<http://www.qsl.net/g1smd/>
<http://home.freeuk.net/g1smd/>
<http://ourworld.compuserve.com/homepages/dstrange/y2k.htm>
<http://dmoz.org/Science/Reference/Standards/Individual_Standards/ISO_8601/>

<ftp://ftp.funet.fi/pub/ham/misc/g1smd.zip>
<ftp://ftp.qsl.net/pub/g1smd/>


[2002-07-12]

.end

I have a Internet application?
Would like to know the UTC offset. Usually have the server domain.  The
domain code is the ISO 2 character country code. (xx)
There are about 350 server domains.
4/5 of these domains do not have any daylight time.  Therefore the UTC offset
is fixed based on the domain.
Their time zone can be determine by the country code.
        I permit either the 2 letter or the 3 letter ISO code.
That leaves about 70 domains with daylight time.
90% have one time zone, so over 60 domains I have the rules to determine when
it is standard time and when it is daylight.
        Except for Iran and Israel, they do not use the Gregorian calendar to
determine the dates
        All others have rules that can be programmed.  European Union has a
common set of rules for daylight.  Country code can be used to determine time
zone and UTC offset for Europe.

United States, Canada, Australia, Russian have the problem because of
multiple time zones (except for Islands like New Zealand) and China covers
five times zones but is all one time zone.

United States and Canada, the states codes are unique, and therefore they can
be used to determine time zone (Arizona, Hawaii, Indiana (except three small
areas) and Saskatchewan do not have daylight which is no problem)  (but have
duplicate of AST for Alaska and Atlantic Standard Time)

Australian has two territories with the same state code and Canada and US
State code.  Therefore for Australia need both the country and state code.

In other words, either with the country codes or state (territory) codes, I
can determine the UTC offset for most of the world.

If anyone has a better idea, please let me know.  Even without daylight one
must have a method to determine what is the UTC offset for a country.

What is your solution?