Abstract
There is somewhat large confusion about what the different dates in Atom actually means, and what they are supposed to be used for. This pace tries to clarify this. It also modifies the Date Constructs to be based on RFC 3339 instead of W3CDTF or XSD DateTime.
-
Some notes on dates on MSDN (not only applicable to the .NET framework)
Status
Open.
This pace supersedes PaceDateAsbjornUlsberg.
Rationale
Clarify what the different dates in Atom is and how they should be used, and base all Date Constructs on RFC 3339.
Proposal
Replace or append to section 3.3, 4.13.6, 4.13.7 and 4.13.8 the following:
3.3 Date Constructs
A Date Construct is an element whose child content is an RFC 3339 Date-Time string [RFC 3339]. If nothing else is stated for a construct, the following rules apply:
-
The date MUST have a time zone designator whose value SHOULD be "+00:00" or "Z". When the UTC time is known but the local time zone of the author is unknown (eg. as a centralised hosting service might know), the time zone designator SHOULD be "-00:00".
-
The value SHOULD be a historical, and therefore not a future date.
-
The date and time separator "T" MUST be present in all datetime strings and MUST be a capital letter "T".
-
The UTC timezone offsett of "00:00", represented with the letter "Z", MUST be a capital letter "Z".
If a Date Construct does not exist in an Atom document, it MUST NOT be assumed to have the semantic or value of any other Date Construct.
4.13.6 Date Constructs of "atom:entry"
An atom:entry MUST contain at least one Date Construct. Which of the following Date Constructs it provides is up to the producer to decide, but at least one of them must be present in each atom:entry.
4.13.6.1 "atom:a" Element
The "atom:a" element is a Date construct that indicates the time that the entry was created. atom:a SHOULD be provided by a publishing tool and not by a human. atom:entry elements MAY contain an atom:a element, but MUST NOT contain more than one.
Consumers MAY choose to sort entries based on this value.
4.13.6.2 "atom:b" Element
The "atom:b" element is a Date Construct, giving the first date of formal issuance (e.g., publication) of the entry. atom:b SHOULD be provided by a tool and not by a human. atom:entry elements SHOULD contain an atom:b element, but MUST NOT contain more than one.
Publishers MUST NOT change the value of atom:b element over time. If an atom:entry is re-issued at several different locations, atom:b MUST NOT be altered to indicate this change in the entry's state. Consumers MAY choose to sort entries based on this value.
4.13.6.4 "atom:d" Element
The "atom:d" element is a Date Construct, giving the date associated with the contents of the entry, which might not be related to events in the publishing process. Typically, atom:d will be associated with the creation or availability of the resource, but its semantics is largely up to the publisher to define.
atom:d SHOULD NOT be provided by a publishing tool, but rather by a human. Publishing tools SHOULD try to find and express their semantics in one of the other Date Constructs. atom:entry elements MAY contain an atom:d element, but MUST NOT contain more than one.
Consumers MAY do whatever they want with this date, as its meaning is defined by the publisher.
The content of an atom:d element MAY be more than, less than and equal to the variable "now". That means that atom:d MAY contain a date in the future. It also MUST according to RFC 3339 have a time zone designator. Since atom:d is a subjective date, the timezone SHOULD be local, provided with the format "+hh:mm". It MAY, however, be "+00:00" or "Z" when the local timezone is UTC, or "-00:00" if the UTC time is known but the local time zone is unknown (eg. as a centralised hosting service might know).
4.13.6.5 "atom:e" Element
The "atom:e" element is a Date Construct that indicates the time that the entry was last modified. "Modification" of an entry includes addition, changes, or deletions of child elements of the entry, both in and outside of the Atom namespace. atom:e SHOULD be provided by a publishing tool and not by a human. atom:entry elements SHOULD contain an atom:e element, but MUST NOT contain more than one.
Publishers MUST change the value of this element when a change occurs in the entry, however the value does not imply or indicate any significance of the change that has occurred. Publishers may change the value of this element for any reason, even if no corresponding change is represented elsewhere in the atom:entry. Publishers may provide more than one instance or version of the same atom:entry within the same atom:feed (ie. with equivalent atom:id values), consumers MAY choose to only record, process, or present the atom:entry with the latest atom:e value.
Impacts
Not much. Tries to be friendly with existing publishing tools and practice, but encourages everyone to provide as many dates as possible.
Notes
See also: PaceTheOneTrueExplanationOfDateElements.