Define four date constructs, one of which must be present in each entry.
Withdrawn. See PaceDateAntoneRoundy2 instead.
A number of events in the publication process have been identified of which many members of the WG have expressed interest in knowing the timestamp. However, requiring any particular timestamp to be present in all entries would be impossible or burdensome to various existing publishing systems. This proposal attempts to balance the desire for as much information as possible with the need to accomodate systems where not all of the information is available.
Replace sections 3.3, 5.6, 5.7 and 5.8 with the following:
3.3 Date Constructs
A Date Construct is an element whose content is an RFC 3339 Date-Time string [RFC 3339]. Except as otherwise specified, the following additional requirements apply:
The date MUST have a time zone designator whose value MUST be "+00:00", "-00:00" or "Z".
The date and time separator "T" and the time zone designator "Z" MUST be capitalized.
Note: Publishers wishing to express additional timestamps beyond those defined below MAY use elements defined by dcterms. dcterms defines created, valid, available, issued, modified, accepted, copyrighted, and submitted, but defines each in terms of W3CDTF. Both W3CDTF and RFC 3339 are profiles or subsets of ISO 8601, and in general RFC 3339 is a subset of W3CDTF. Consumers will need to be aware that the dates they find in dcterms MAY be of a lesser precision (e.g., "2004" is a valid W3CDTF date). When elements from the dcterms extension module are present in an Atom feed they SHOULD be expressed using the smaller RFC 3339 profile.
5.6 Date Constructs of "atom:entry"
An atom:entry MUST contain one or more of the following Date Constructs. Refer to section 3.3 Date Constructs for formatting requirements.
5.6.1 "atom:a" Element
The "atom:a" element is a Date Construct indicating the date and time that the entry was first published, whether in this or another feed. The value of atom:a MUST NOT be altered except to correct errors in its value. atom:entry elements MAY contain an atom:a element, but MUST NOT contain more than one.
5.6.2 "atom:b" Element
The "atom:b" element is a Date Construct indicating the most recent date and time that the entry was altered in any way, with one exception: if external data, such as advertisements, are being incorporated into the entry, atom:b need not be updated when that data changes. atom:entry elements MAY contain an atom:b element, but MUST NOT contain more than one.
5.6.3 "atom:c" Element
The "atom:c" element is a Date Construct indicating the most recent date and time when a change was made to the entry which the publisher wishes to bring to the attention of subscribers. Such changes would typically not include minor adjustments like spelling and grammatical corrections. atom:entry elements MAY contain an atom:c element, but MUST NOT contain more than one.
5.6.4 "atom:d" Element
The "atom:d" element is a Date Construct indicating a date and time which the publisher wishes to associate with the contents of the entry. It need not be related to events in the publishing process. The time zone designator for atom:d MAY be any valid time zone designator as specified by RFC 3339. Note that alphabetical time zone designators other than "Z" (ie. "PST") are not valid in RFC 3339 dates. atom:entry elements MAY contain an atom:d element, but MUST NOT contain more than one.
Consuming software will need to be able to deal with entries that don't contain each Date Construct element, and perhaps with feeds whose entries each contain a different collection of Date Construct elements. This will result in ambiguity in sorting orders to the extent that entries don't include the same elements.
The technical requirements posed by requiring sorting of entries with different sets of Date Construct elements should not be particularly onerous. When processing a feed, consuming software could have its own internal space for storing the "sorting date", which would be taken from the highest priority Date Constuct that exists in each entry, and then sort based on the internal date field. The issue would be the risk of ambiguity in the sort order.