> The  ISO-8601 duration can minimize the errors.

Maybe.

> It would eliminate different systems getting different  results for
the same
> date/time problem.

Not so much. ISO 8601 allows for virtually unlimited range and
precision, which is OK, for textual interchange, but impractical for
higher performance internal representations.

All the parts of the standard that discuss Universal Time or time zones
specify that everything is based on Coordinated Universal Time (UTC).
But UTC didn't exist before 1961, and didn't assume its present form,
with an integer number of seconds difference between International
Atomic Time (TAI) and UTC until 1972. So isn't it formally incorrect to
use the Z indicator or a time zone offset before 1961?

For the relationship between TAI and UTC see
http://hpiers.obspm.fr/eoppc/bul/bulc/UTC-TAI.history

8601 also requires the use of the Gregorian calendar, which did not
exist prior to 1582, for all dates.  It is easy to extrapolate back.

For time, the concept of time zones and radio time signals synchronized
between countries certainly existed before 1961.  The prevalent time
standard was UT2, a form of rotational time smoothed for seasonal
variation, and high precision clocks were steered to match it.  Until
1972, atomic clocks were steered to it, prior to leap seconds.  Prior
to the introduction of atomic time, I think you could substitute that
with little loss of accuracy.

If you go back another century, there were no time zones, everyone kept
local solar time, and clocks weren't very good anyway.  However there
are records of departure of local time from time on the prime meredian
that are part of the time zone record.

What are you trying to do exactly and what time records are you having
trouble relating to UTC?


--- In ISO8601@yahoogroups.com, "pqrc96" <pqrc96@...> wrote:
>
> All the parts of the standard that discuss Universal Time or time
zones
> specify that everything is based on Coordinated Universal Time (UTC).
> But UTC didn't exist before 1961, and didn't assume its present form,
> with an integer number of seconds difference between International
> Atomic Time (TAI) and UTC until 1972. So isn't it formally incorrect
to
> use the Z indicator or a time zone offset before 1961?
>
> For the relationship between TAI and UTC see
> http://hpiers.obspm.fr/eoppc/bul/bulc/UTC-TAI.history
>

No.

Some people who write in Wikipedia are interested in using
microformats to provide a machine-readable version of important dates
and times, in the hopes that future software will be better able to
mine data from articles. Dates and times in microformat purport to
conform to the ISO 8601 standard, but at least in the case of
Wikipedia, the people interested in implementing this sort of thing
don't have a clear understanding of time zones or the need to use
the Gregorian calendar. Upon re-reading the standard to see if some
of these items could be cleared up, I noticed that the standard has
an oversignt, in that it allows for dates and times before the
beginning of UTC but does not provide a way to specify a time zone
for these dates, because doing so requires UTC. In a standard that
is so careful to explain the meaning of every single character, this
seems like an error. Of course, people will go ahead and extend it
backward however they please, but strictly speaking, they are no
longer using ISO 8601, they are using their own private extension.

--- In ISO8601@yahoogroups.com, "johnmsteele" <johnmsteele@...> wrote:
> . . .
> What are you trying to do exactly and what time records are you
having
> trouble relating to UTC?

In a very strict technical sense it may have been overlooked.


However, prior to atomic clocks, you have to relax the formality of beating in
synch with atomic clocks.  It obviously approximates (within 0.9 s, that is why
leap seconds are used) mean solar time at Greenwich.  Formerly that time was
kept as GMT or UT1 (Note: GMT had a confusing period where astronomers counted
from noon, and civilly, hours were counted from midnight).  GMT was used from
1884 when Greenwich was accepted by international convention as the Prime
Meredian (and used by many nations prior to that).

Your bigger problem is when did political entities switch from local mean solar
time to standard time.  In most places it was adopted first by railroads and
some local entitites, eventually national.  The US was 1918, with some prior use
by individual cities and states.

The "Z" designation for time at Greenwich was used long before UTC.

I think your 1961 boundary can be pushed back to when the country of interest
declared "standard time" (if you can determine how many hours off Greenwich. 
There are a LOT of time zone changes.)

Prior to standard time, there may be a problem, although if you know the
longitude of a place, you could calculate the time shift from Greenwich to the
nearest minute (1 hour/15°).  Rarely are times back then known with any great
accuracy.

--- In ISO8601@yahoogroups.com, "pqrc96" <pqrc96@...> wrote:
>
> Some people who write in Wikipedia are interested in using
> microformats to provide a machine-readable version of important dates
> and times, in the hopes that future software will be better able to
> mine data from articles. Dates and times in microformat purport to
> conform to the ISO 8601 standard, but at least in the case of
> Wikipedia, the people interested in implementing this sort of thing
> don't have a clear understanding of time zones or the need to use
> the Gregorian calendar. Upon re-reading the standard to see if some
> of these items could be cleared up, I noticed that the standard has
> an oversignt, in that it allows for dates and times before the
> beginning of UTC but does not provide a way to specify a time zone
> for these dates, because doing so requires UTC. In a standard that
> is so careful to explain the meaning of every single character, this
> seems like an error. Of course, people will go ahead and extend it
> backward however they please, but strictly speaking, they are no
> longer using ISO 8601, they are using their own private extension.
>
> --- In ISO8601@yahoogroups.com, "johnmsteele" <johnmsteele@> wrote:
> > . . .
> > What are you trying to do exactly and what time records are you
> having
> > trouble relating to UTC?
>

I don't see a problem.

Did the responses answer your question sufficiently?

The problem(s) are not really with the standard.
As you go back in time, UTC doesn't exist, time zones also become less well
defined, measurement of time becomes less accurate, the dates of conversion to
Gregorian vary around the world, political entities and borders change, and
often the author did not record his or her location and "time zone" when noting
an event.

The standard does say that when the standard is used to go earlier that there
should be an agreement among the parties using it.
Wikipedia could document its guidelines to ensure common semantics within
microformats.
Wikipedia can also define some additional metadata to ensure the assumptions
made when assigning a date-time with ISO8601 are kept with it so it won't be
misconstrued.

Note also the existence of a year zero, and guidelines on leap days for dates
before epoch.

tex

--- In ISO8601@yahoogroups.com, "pqrc96" <pqrc96@...> wrote:
>
> Some people who write in Wikipedia are interested in using
> microformats to provide a machine-readable version of important dates
> and times, in the hopes that future software will be better able to
> mine data from articles. Dates and times in microformat purport to
> conform to the ISO 8601 standard, but at least in the case of
> Wikipedia, the people interested in implementing this sort of thing
> don't have a clear understanding of time zones or the need to use
> the Gregorian calendar. Upon re-reading the standard to see if some
> of these items could be cleared up, I noticed that the standard has
> an oversignt, in that it allows for dates and times before the
> beginning of UTC but does not provide a way to specify a time zone
> for these dates, because doing so requires UTC. In a standard that
> is so careful to explain the meaning of every single character, this
> seems like an error. Of course, people will go ahead and extend it
> backward however they please, but strictly speaking, they are no
> longer using ISO 8601, they are using their own private extension.
>
> --- In ISO8601@yahoogroups.com, "johnmsteele" <johnmsteele@> wrote:
> > . . .
> > What are you trying to do exactly and what time records are you
> having
> > trouble relating to UTC?
>

Sent via BlackBerry from T-Mobile

>often the author did not record his or her location and "time zone" when noting
an event.

True, so we may never know the offset, but that doesn't interfere with using ISO
8601. You can simply indicate "local time" by not specifying the offset.

> (aren't offsets are currently limited to hours & minutes from UTC?).

Yes, but seconds generally aren't important in day-to-day events anyway.
If you're going to try to calculate an offset to great precision you may need to
account for continental drift. :)

Sent via BlackBerry from T-Mobile

The original message was received at 2009-05-26 23:15:29 -0400
from postoffice.local [10.0.0.1]

    ----- The following addresses had permanent fatal errors -----
<bam@... Below is a copy of another message that I tried to post to
the list>

    -----Transcript of session follows -----
... while talking to postoffice.local.:
>>> RCPT To:<bam@... Below is a copy of another message that I tried
to post to the list>
<<< 550 5.1.1 unknown or illegal alias: bam@... Below is a copy of
another message that I tried to post to the list
550 <bam@... Below is a copy of another message that I tried to post
to the list>... User unknown

There is 1 message in this issue.

Topics in this digest:

1a. Re: UTC didn't exist before 1961
     From: piebaldconsult


Message
________________________________________________________________________
1a. Re: UTC didn't exist before 1961
     Posted by: "piebaldconsult" PIEBALDconsult@... piebaldconsult
     Date: Sat Apr 4, 2009 8:44 am ((PDT))

No.






Messages in this topic (3)





------------------------------------------------------------------------
Yahoo! Groups Links



------------------------------------------------------------------------

Your first mail may have bounced, it looks like the from address was messed
up.
However, your subsequent mails seemd to be forwards of the bounced mail and
those went thru.

You may want to use the website to make your comments.

tex

I started this thread. After seeing the responses, I don't really see anything
that would change my ideas, but knowing that my thoughts have been reviewed by
this group makes me feel more confident in them.

In the future, I will not emit ISO 8601 dates with a Z suffix or a time zone
unless the date is on or after January 1, 1972, the date of the formal adoption
of the name Coordinated Universal Time. I will reject incoming dates in that
format if I am able to determine that time zones had not been adopted in the
place in question on the date stated. I will reject incoming dates with a time
zone offset that is not a multiple of 15 minutes.

I agree with Tex's remarks.  But I would add the following three points:

*Dates don't have time zones.  Only times or "date and time" representations
have time zones.  Your views on UTC should never affect a date (standing alone).

*Due to its use in astronomy tables, celestrial navigation, etc, GMT or mean
solar time on the Greenwich meredian had relevance long before standard time
zones, and the "Z" or Zulu notation has been used long before UTC.  If a time
can be determined to be mean solar time on the Greenich meredian (within a
second, or so), a Z notation seems perfectly sensible to me.  I would advocate
its use, even before it was actually used, just as ISO8601 demands redating
dates prior to 1582 to the Gregorian calendar, not the Julian calendar.

*Prior to standard time zones, the time offset to GMT was an important concept. 
If you feel compelled to "destroy the evidence", I would suggest you replace it
with the longitude of the official clock in the location.  But a time
description is equivalent.  Usually an hh:mm description to the nearest minute
would suffice, but in some cases an extension of the time zone format to
hh:mm:ss might be warranted for documented local mean solar time.  However, in
the time period where this was true, local time may have sufficed perfectly
well, and the populace may have been indifferent to what time it was near
London.

It may pay to ask questions about "suspicious looking" time zones, but, to me, a
policy of automatic rejection does not make sense.

--- In ISO8601@yahoogroups.com, "pqrc96" <pqrc96@...> wrote:
>
> I started this thread. After seeing the responses, I don't really see anything
that would change my ideas, but knowing that my thoughts have been reviewed by
this group makes me feel more confident in them.
>
> In the future, I will not emit ISO 8601 dates with a Z suffix or a time zone
unless the date is on or after January 1, 1972, the date of the formal adoption
of the name Coordinated Universal Time. I will reject incoming dates in that
format if I am able to determine that time zones had not been adopted in the
place in question on the date stated. I will reject incoming dates with a time
zone offset that is not a multiple of 15 minutes.
>

[2009-May-30]


Ten years on, and some communities are still having healthy debate...
http://www.reddit.com/r/geek/comments/870qk/is_it_just_me_or_is_the_iso_8601_cal\
endar_date/
...covering the same stuff we thrashed out a decade ago.

I guess that's because perhaps 90% of the people on the internet now,
were not using the web way back then. I see ISO 8601 widely adopted
on web sites and in software packages, but there's still a long way to go.


Cheers,

Ian.


[2009-05-30]

> In the future, I will not emit ISO 8601 dates with a Z suffix or a time zone
unless the date is on or after January 1, 1972

Personally, I think that would be fairly silly.

On 2009-05-26, pqrc96 penned thusly:

>  In the future, I will not emit ISO 8601 dates with a Z suffix or a time zone
>  unless the date is on or after January 1, 1972, the date of the formal
>  adoption of the name Coordinated Universal Time. I will reject incoming dates
>  in that format if I am able to determine that time zones had not been adopted
>  in the place in question on the date stated. I will reject incoming dates
>  with a time zone offset that is not a multiple of 15 minutes.

    That's fine if your application imposes such restrictions, but it is
    not what ISO 8601 requires.

    ISO 8601 fixes some notations but it does not constrain the meaning of
    these notations. Other standards employ some of these notations and
    endow them with specific semantics.

    For ISO 8601 timestamps with and without time zone differences,
    XML Schema ([http://www.w3.org/TR/xmlschema11-2/]) is an example. It
    defines several operations with these timestamps (such as comparison and
    difference), and gives the semantics of these timestamps as "points on
    a time line". This is very general, and makes these notations
    usable for expressing epochs in all kinds of time scales, not just UTC
    and zone times: navigators can use it for GPS time, astronomers for TCB,
    and historians for apparent solar time at Jerusalem.

    Of course it is possible to further restrict the meaning to mean
    solar time and the civil zone times introduced since 1895, or even to
    time scales based on TAI, but this is not required by ISO 8601.

    Michael Deckers

Hi,

How do I represent the first three months of every year in ISO 8601. I know one
can represent a period by "P3M" and one can represent a  recurring period with
the "R" but I can't work out how to represent recurring periods with breaks
between these periods.

I believe R/1990-01/P3M represents three month periods since January 1990but
that would be January to March, April to June, July to September and October to
December since January 1990.


Does something like R/1990-01/03/P1Y represent January to March 1990 and then
every year after that?

Thanks.


Jhock96

Hi,

How does one show the first quarter (January to March) of every year using ISO
8601.  I know that recurring is represented by "R" and that a period for the
first quarter of a year can be represented as "P3M" so I can show that the first
quarter of 1990 is "1990-01/P3M".  However, if I try to show this as recursive
"R/1990-01/P3M" then, I think, this indicates every quarter from 1990.

How do I show that there are gaps for the other three quarters of the years? IE.
Every January to March from 1990.

I would also prefer to not have to start in a particular year (IE. Every January
to March) but I will if I have to.

Thanks.


Jhock96

I'm not sure you can.  In 2004 version, section 2.1.17 is clear that recurring
time interval is defined as consecutive time periods.

What you want requires a specification of two durations, the initial period, and
the repeat rate.  ISO8601 does not appear to provide for this case.

Even if it did, I think the form would be too arcane to be considered human
readable.  If it were defined, a compliant computer would have to be able to
read it.  However, I think it is not defined.

--- In ISO8601@yahoogroups.com, <john.hockaday@...> wrote:
>
> Hi,
>
> How does one show the first quarter (January to March) of every year using ISO
8601.  I know that recurring is represented by "R" and that a period for the
first quarter of a year can be represented as "P3M" so I can show that the first
quarter of 1990 is "1990-01/P3M".  However, if I try to show this as recursive
"R/1990-01/P3M" then, I think, this indicates every quarter from 1990.
>
> How do I show that there are gaps for the other three quarters of the years?
IE. Every January to March from 1990.
>
> I would also prefer to not have to start in a particular year (IE. Every
January to March) but I will if I have to.
>
> Thanks.
>
>
> Jhock96
>

>  "R/1990-01/P3M" then, I think, this indicates every quarter from 1990.

I agree with that interpretation.

On the other hand, I expect that you and your partners in interchange could
mutually agree that it means what you want; repeated three-month periods
beginning each January first.