On Sunday, July 11, 2004, at 10:31 AM, Sam Ruby wrote:
We need to better define what we expect people who "work with" these dates can expect. I explored this in
http://www.intertwingly.net/blog/2003/07/01/Subjective-and-objective- dates
...
There is no question in my mind that <modified> dates should be strictly ordered, so either an indication of timezone or canonicalization to UTC would be required. Doing so would allow aggregator authors to order entries across all weblogs, if they chose to do so.
What Bloggers calls Post Date and Time [1], and what LiveJournal simply calls Date and Local Time of an entry is different. Qualitatively different. It is subjective. It's primary purpose is for display. For human consumption.
...
The most you can assume about this particular date is that it is the date that the author wants associated with the entry, nothing more, nothing less.
...
One date is objective, intended to be processed by cold hard machines. One date is subjective, intended to be processed by warm squishy humans.
On Sunday, July 11, 2004, at 10:46 PM, Graham wrote:
A major change should result in a new atom:issued
Okay, here's an attempt at a methodical approach to defining what date elements we need and what the requirements and recommendations should be for each.
Dates (where "date" = "date and time") that might be associated with an entry:
1) objective creation date
2) each objective major modification date
3) each objective minor modification date
4) each objective publication date
5) any subjective creation date the author may wish to associate with the entry
6) any subjective major modification date the author may wish to associate with the entry
7) any subjective minor modification date the author may wish to associate with the entry
8) any subjective publication date the author may wish to associate with the entry
Questions: A) Which of these should appear in the feed? B) Which of these can be consolidated into a single element in a feed? C) What timezone requirements/recommendations should each carry?
Interested parties:
I) Author: Most interested in 8. Prefers their local timezone.
II) Publishing client software: Just an intermediary--probably doesn't care about anything.
III) Publishing server software: Most interested in 2-4, possibly including all iterations. No strong timezone preference.
IV) Aggregators: Most interested in 2-4, perhaps including only the first, last, or first and last of each. Perfers UTC.
V) Feed reader software: Most interested in 2-3 for ordering and determining whether to call something "new" or "updated". No strong timezone preference.
VI) Human reader: Most interested in the last of each in 2-3 and one of 4 or 8 (depends on the person)--possibly also interested in the first of 4 or 8--and may wish the timezone to be either the author's local timezone or their own local timezone.
Comments (correct me if I'm wrong or you disagree--these are my perceptions and opinions):
i) The publishing software can store the dates in whatever timezone they want. They can present it to the author in the author's local timezone, and can publish it as best benefits everyone else.
ii) Nobody really cares about 5-7.
iii) Nobody reading the feed really cares about 1, so including it in the feed should be optional. I suppose there may be uses for it, but I wouldn't complain if it weren't even supported.
iv) Nobody reading the feed cares much about anything that occurred before the first 4.
Conclusions: a) 2-4 and 8 are the only dates that may need to be in the feed. b) At most the first and last of each should appear in the feed. c) Only 8 should be allowed to omit the timezone. d) 2 could be used instead of 4 in the feed.
Proposed Date Constructs:
atom:first-issued or atom:first-published (first 4)
An objective publication date. REQUIRED. MUST specify a timezone (which might be -00:00 if the timezone is unknown) which MUST be numeric.
atom:issued or atom:published (last 8)
A subjective publication date. OPTIONAL. It is RECOMMENDED that it include a timezone, that the timezone be numeric, and that it be the author's timezone, or the timezone relevant to the content of the entry (for example, if I, in Utah, am writing about something that happened in Iraq, I might use Iraq's timezone).
atom:modified (last 2)
The objective date when the last major change--a change which alters or non-trivially expands the message--was made to the entry. REQUIRED if different from atom:first-issued|published. It MUST specify a timezone (which might be -00:00 if the timezone is unknown), which MUST be UTC.
atom:updated (last 3)
The objective date when the last minor change--for example a spelling correction, clarification which doesn't expand the message, etc.--was made to the entry. RECOMMENDED if different from atom:first-issued|published and later than atom:modified. MUST NOT be included if earlier than atom:modified. MUST specify a timezone (which might be -00:00 if the timezone is unknown), which MUST be UTC.
I would also propose that the spec text for each Date Construct, or some text appearing before the list of Date Constructs, point out that the requirements for each are different because some are intended to use by software and others for presentation to humans.
The "objective" dates should have spec text to point out that these dates MUST NOT be modified except to correct for errors in the actual timestamp (for example, if the computers clock was incorrect).
Note that the dates that are required to be specified in UTC may be converted by client software to the timezone indicated in atom:issued|published if it appears in the feed. All dates may also be converted to the user's local timezone.