RE: a methodical approach to defining what date elements we need

["Roger B." <roger@xxxxxxxxxxxxxxxxxx>]

To Sam:
> You
> described this date as some fanciful user entered date
> that could potentially be meaningless. What
> MovableType and co provide is a way for the user to
> specify the issued date which is not the same as the
> user being able to say "43rd day of the 31st month of
> the millionth year" as the date.

Yikes! If that's what people have been talking about when they discuss
"subjective" or "user-defined" dates, then I have been very, very confused.

When I use those terms, I am referring to an actual date. The user enters
"2004-07-14", "07/14/2004", or "Wed, 14 Jul 2004", and the app parses the
submitted data into a raw date that is tucked away in the database. During
output, the date is transformed into whatever format (822, 8601, etc.) is
required by the user's template. 

So I am most definitely *not* arguing in favor of forcing aggregator authors
to figure out how to sort arbitrary strings masquerading as dates. What I
*am* arguing for are:

(1) The Atom-equivalent of RSS pubDate. Meaning, a date that indicates where
an entry falls within the chronological flow of a blog/feed.

(2) An understanding that (1) may be user-defined (see above), and that the
user may change the value of (1) at whim.

(3) A "this entry was last updated at this time" element, usually referred
to in Atom terms as "modified" and usually machine-defined.

If necessary, I can also provide a distinct "created" date, but outside of
migration between tools, there's not much value in it. 

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/