Right. Doesn't the standard call for a proleptic Gregorian calender for dates before 1582 after the present (and that more digits/negative dates are allowed as long as there is mutual agreement)? If you ask me, I believe offsets should be able to contain as much precision as any other time perhaps the standard should be amended for that at least (aren't offsets are currently limited to hours minutes from UTC?).
Sent via BlackBerry from T-Mobile
From: "Tex Texin" Date: Mon, 25 May 2009 08:31:19 -0000 To: <ISO8601@yahoogroups.com> Subject: [ISO8601] Re: UTC didn't exist before 1961
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? >
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...
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...
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...
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...
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...
Right. Doesn't the standard call for a proleptic Gregorian calender for dates before 1582 & after the present (and that more digits/negative dates are allowed...
... 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...
I was thinking of historical examples like the offset The Netherlands used sometime in the last 100 years that had an offset precise to the centisecond....
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...
Hi, You are welcome to do whatever you want of course, but I don’t think this is what was suggested or recommended and I don’t think you should in any way ...
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...
John Good comments. 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, ...
... 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...
... 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....
Tex,  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...
When I mentioned in an earlier post that I would reject certain date-times in the ISO 8601 format, I meant that I would halt processing or flag them for...
Having problems with message search?
Online Now 
Send Email
