2193RE: [ISO8601] Re: UTC didn't exist before 1961
- May 29, 2009Tex,I agree with the dilemma you pose. In reality, that means date alone often does not suffice and you must consider time of day as well.However, in being "anal" about interpretting the standard, there is no reference to time zone in the formats allowed for pure dates. There are formats specified for time and for complete "date and time" references. (sections 4.2 and 4.3, but NOT section 4.1)Any problem must be solved by specifying a place (relative to the date) or by appending a time and time zone. The standard does not make a provision or provide a format for specifying a time zone with a standalone date. (At least in my view. You are better versed in ISO8601 than I; if you can find a section that addresses this, I'll certainly accept it.)
--- On Fri, 5/29/09, Tex Texin <textexin@...> wrote:
From: Tex Texin <textexin@...>
Subject: RE: [ISO8601] Re: UTC didn't exist before 1961
Date: Friday, May 29, 2009, 7:54 AM
I am surprised by your comment on dates. Dates definitely do have time zones. Since time zones span 25 hours, without mention of the zone, coordinating on date alone could result in a miss with no overlap between them.
I know people that needed to be in Australia on date x.
Since the flight from their starting point takes 20 hours or so they would plan to leave on day x-1.
Unfortunately since their location was about 15 hours behind Australia, they really needed to leave at x-2
x-2 + 15 hours time zone difference + 20 hours flying time = x-2 + 1.5 days (35 hours) =~ x
Leaving at day x-1 they missed their appointment.
I have seen where it makes a difference documenting and comparing historic dates of events that occurred in widely separated locations.
From: ISO8601@yahoogroups .com [mailto:ISO8601@ yahoogroups. com] On Behalf Of johnmsteele
Sent: Friday, May 29, 2009 4:39 AM
To: ISO8601@yahoogroups .com
Subject: [ISO8601] Re: UTC didn't exist before 1961I 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.
- << Previous post in topic Next post in topic >>