UserPreferences

PaceEntryDates


Abstract

The [WWW]Atom Syndication Format 0.3 pre-draft describes various types of dates that may be associated with an atom:entry. This proposal clarifies their meaning to make them more meaningful and usable.

Status

Open

Rationale

It is clear that the entire date specification needs rethinking. Because there are strong interrelations between the definitions of each date, it is not possible to respecifies each date individually. This proposal therefore respecifies all three dates at once.

Proposal

Replace sections 4.13.6, 4.13.7, 4.13.8 with the following:

"atom:issued" Element

"atom:created" Element

"atom:modified" Element

Impacts

Atom 0.3-based implementations will generally not be compatible with these changes. Therefore all implementors would need to reinvestigate how they use dates. This is unavoidable.

Notes

Since atom:modified and atom:created are optional, timezones can be SHOULDs rather than MUSTs, since any implementation requiring timezone information may act as if the dates are not present. This should work around the LiveJournal problem.

GrahamParks 2004-02-27

Q & A

Answer Me: If the TZD is absent for modified or created, what TZD should be assumed?

GrahamParks: The time zone is unknown and undefined. No assumption can be made. "any implementation requiring timezone information may act as if the dates are not present".

Answer Me: "No assumption can be made" -- is that a MUST NOT or a SHOULD NOT? "..may act as if the dates are not present" -- MAY or SHOULD?

Is it inappropriate for the Atom spec to make any recommendations here at all? If the spec doesn't make recommendations then assumptions will be made regardless by various implementations (eg. sorting a list by modified date).

GrahamParks: You can make whatever assumption you like, if you can live with the 1 in 24 chance of being right. You can't compare two dates where the time zone of one of them is unknown, so you just cannot sort by them without making possibly incorrect assumptions.

Answer me: I've also thought of a third choice for the assumption: local time. There is precedent for this in the iCalendar spec - a datetime with no TZD is taken to be at local time, regardless of where in the world that may be.

GrahamParks: The reader's local time? No, it's the writer's. A date with no time zone indicates nothing more than "At the time, somewhere in the world".

Answer Me: "material modification" definition?

GrahamParks: A provisional definition would be that it's when entries in the underlying database are changed. If you modified the script that generates your Atom feed, you wouldn't have to increment all the modification dates. But clearly, study of use cases is required before a spec-text definition can be established.

Answer Me: In many existing systems, updates to the issued date are done within the context of the entry editor. Updating the issued date will therefore force an automatic change in the modified date. How is this compatible with the offered definition of issued?

GrahamParks: Discuss on list please.

I agree there's a problem here, but think a more rigourously-specified model for the different dates is needed; e.g., what are the state transitions? atom:issued particularly suffers from this -- MarkNottingham

See Also


CategoryProposals