[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PaceDates


On Thursday, July 29, 2004, at 02:15 PM, Asbjørn Ulsberg wrote:
On Thu, 29 Jul 2004 18:20:36 +1000, Eric Scheid <eric.scheid@xxxxxxxxxxxxxxx> wrote:
I suggest you gather all the date constructs under point 4.13.6, and then
numbered sub-points for each date element (ie. 4.13.6.1 for modified,
4.13.6.2 for issued, etc).
Good idea. Done. Would it be a good idea to group the dates in a <dates> element, btw?

I don't see any value in grouping under a <date> element. Anyone else? If there's no value in it, then let's be less verbose. I DO like the idea of grouping the date elements within the spec--I think it improves spec readability.

why the deprecation of 'date'?

Because it's a wildcard date. No one knows what the publisher's mean with it, so we should encourage them to move over to the more tightly specified dates 'issued', 'created' or 'modified'. They may provide atom:date for as long as they want, but I think that the use of such ambiguous elements should be discouraged.

-1. The subjective date is not only for legacy support--it also enables the author to indicate a date related to the CONTENT or MEANING of the entry, as opposed to timestamping the events that occurred in the process of PUBLISHING the entry.

The content of an atom:date element MUST according to RFC 3339 have a time zone whose value SHOULD be "+00:00" or "Z". The time zone >>> MAY,
however, be "-00:00" when the time is known to be correct UTC, but the
time zone is unknown, or be '+hh:mm' when the time zone is known.

My impression was that it is MORE accurate to use "-00:00" than "+00:00" or "Z" when normalizing from some other timezone to UTC. Doesn't "+00:00" or "Z" imply that UTC IS the "origin" timezone? When it is said that "-00:00" means that the origin timezone is unknown, I think that means that either the clock of the computer that generated the timestamp is set to UTC, thought it may not be located in that timezone, or that the timestamp has been normalized to UTC, thus discarding the originally known timezone information. I can't imagine that it means "I looked at the clock with the local time and computed the UTC time, but I have no clue what timezone I'm in." If your clock reads local time and you can compute UTC, you DO know what timezone you're in.

I don't think it's terribly important whether "+00:00", "-00:00" or "Z" is used, but if we ARE going to encourage one or two over the other(s), then let's be sure we're doing the most correct thing.