Abstract
The 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
-
Currently, the meaning of the three dates (modified, created, and issued) is defined only by their names, leaving them very open to interpretation. There needs to be clear definitions that pin down exactly what they should mean, but in general terms applicable to all uses of Atom.
-
An item that has not been modified should only be required to include information about when it was created (or issued). The current specification requires atom:modified in all cases.
-
"If atom:created is not present, its content MUST considered to be the same as that of atom:modified." Since there is no requirement for atom:created to be present when it differs from atom:modified, this requires consumers to make an assumption that may or may not be true, often significantly.
-
Date modified information is not available on some systems, and is only required for a small subset of uses, therefore it should not be required.
-
Currently, atom:issued may omit timezone information. Because atom:issued will generally be a mechanically produced timestamp, there is no reason to omit this information.
-
Currently, dates are strongly encouraged to be changed to the UTC time zone. This may lead to some consumer implementations incorrectly assuming all dates are UTC, or publishers to be unsure whether it is acceptable to publish dates in timezones other than UTC. This situation would be bad for interoperability, so the recommendation has been removed.
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
-
The "atom:issued" element is a Date construct that indicates the time that the entry was made available for syndication. If an entry has been made available on several distinct occasions, this represents the date of the latest re-issue. atom:entry elements MUST contain an atom:issued element, but MUST NOT contain more than one.
The content of an atom:issued element MUST include time zone information.
"atom:created" Element
-
The "atom:created" element is a Date construct that indicates the time that the entry was written, or otherwise created. atom:entry elements MAY contain an atom:created element, but MUST NOT contain more than one.
The content of an atom:created element SHOULD include time zone information.
If atom:created is not present, its content MAY be considered to be the same as that of atom:issued. Therefore if atom:issued and atom:created differ sginificantly, atom:entry elements should contain an atom:created element.
"atom:modified" Element
-
The "atom:modified" element is a Date construct that indicates the time of last material modification to the entry. atom:entry elements MAY contain an atom:modified element, but MUST NOT contain more than one.
The content of an atom:created element SHOULD include time zone information.
If atom:modified is not present, its content SHOULD NOT be considered to be the same as that of atom:issued or atom:created. Furthermore, the entry SHOULD NOT be assumed to have not been modified since creation.
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?
-
+0000 or Z
-
the TZD of atom:issued
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