Re: Next step on Dates

[Antone Roundy <antone@xxxxxxxxxxxxxx>]

I've been a little surprised at the near total lack of response to 
Sam's "Accuracy and Precision in dates"[1], so I'll bring it up again.  
Here's the executive summary of my response[2]:

Questions:
1) What are we trying to accomplish with dates in Atom?
2) What Date Construct definition(s) would maximize our ability to 
accomplish that?

Possible answers:
To #1:
A) Enable a desirable sort order
B) Provide a meaningful display date

To #2:
The following 2:
I) "Updated"--the objective date of the most recent modification which 
the publisher subjectively decided was significant enough to highlight.
II) A subjective "display" date.

FAQ:
i) "What if I want to sort by 'Issued'?"
You can get close enough (see Sam's email[1]) by caching "Updated" the 
first time you see an entry, and continue to sort by that value even if 
the publisher modifies "Updated".

ii) "What if I don't want to change the date in my feed, even if I make 
a huge modification?"
Fine.  Don't change it.  You've subjectively decided not to highlight 
the change, so the unchanged date fits the specification.

Antone

[1] http://www.imc.org/atom-syntax/mail-archive/msg08457.html
[2] http://www.imc.org/atom-syntax/mail-archive/msg08458.html

=======================================

P.S. If this all sounds reasonable to you, see 
PaceDateAntoneRoundy2[3], which never seems to have made it on to the 
issues list, and the announcement of which, in another surprise to me, 
garnered a similar amount of discussion as "Accuracy and Precision in 
dates".  The following is an except from a response I sent to an 
offline message about this proposal:

> I think there are a number of different axes along which people are 
> divided.  I think the proposal deals with a lot of the conflicts in a 
> way that I HOPE will make it possible to build consensus:
>
> * In the core vs. by reference: we define something in the core which 
> should cover most uses, but welcome people to use extensions to do 
> other things if they want to (which they always were welcome to do).
>
> * Duplication in the core of the things we think are most important 
> from dcterms vs. no duplication: no duplication, but a clear pointer 
> toward where to find the things that have already been defined in 
> dcterms if you need them.
>
> * Consumers HAVE TO be able to deal with a lot of dates, any of which 
> may or may not be present vs. keep the requirements simple: Keeps the 
> requirements simple, but points the way clearly for people who want to 
> do more complex things.
>
> * Have a clear way to specify a variety of time stamps vs. just bail 
> and stick with something not much better than RSS because it's too 
> hard to find consensus: bail on building the specific stuff into the 
> core, but provide a clear pointer for how to specify that stuff if you 
> want to.

[3] http://www.intertwingly.net/wiki/pie/PaceDateAntoneRoundy2