UserPreferences

PaceDateAntoneRoundy2


Abstract

Define two Date Constructs which do not correspond to anything in dcterms, and encourage the use of dcterms dates for expressing other dates and times. One of the two core dates is required, and use of the more objective of the two is strongly encouraged.

Status

Open

Rationale

Given that we clearly will not achieve consensus on a moderate to large set of Date Constructs in the Atom core, and that there are objections to duplicating dates from dcterms in the Atom core, this proposal defines two which many members of the WG have expressed interest in, but which do not correspond to anything defined by dcterms. The requirements of this proposal cater to the fact that some existing systems can only provide a so-called subjective timestamp, while encouraging the use of a more objective timestamp. This proposal attempts to cover the needs of most producers with dates in the Atom core, while pointing a direction to go for those who need more.

Proposal

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:

5.6 Date Constructs of "atom:entry"

Each atom:entry MUST contain one or more of the following Date Constructs. Publishers wishing to publish dates for events in the publishing processes not described by these elements MAY use elements defined by dcterms, such as [WWW]created, [WWW]valid, [WWW]available, [WWW]issued, [WWW]modified, [WWW]accepted, [WWW]copyrighted, and [WWW]submitted. Note that dcterms defines each in terms of [WWW]W3CDTF. Both W3CDTF and RFC 3339 are profiles or subsets of [WWW]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.1 "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, which would more appropriately be expressed using dcterms:modified. atom:entry elements SHOULD contain an atom:c element, but MUST NOT contain more than one.

atom:c MUST be expressed in UTC. Thus, it MUST include one of the following time zone designators: "+00:00", "-00:00" or "Z".

Consuming applications MAY ignore changes to atom:c, and continue to use the value found in this element the first time they accessed a particular entry.

5.6.2 "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. For example, atom:d might be used to express the date which a journal entry describes, although that entry might have been written at a later date.

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.

Impacts

Notes


CategoryProposals