[uf-dev] A sensible alternative for representing dates

[Marty Alchin]

This is my first foray into the microformats community, so I apologize
if I'm missing some necessary past history on this topic. I'm sure
it's been discussed before, I know it's being discussed now, and I'd
just like to add another option to the discussion.

Also, yes I realize that by using the word "sensible" in the subject
of this email, I'm introducing a likelihood of wild tangents regarding
the subjectivity of such a word. I'll just try to stem it by saying
that yes, I do realize it's subjective, and it's my opinion that what
I'm proposing is sensible. Enough said.

Since the BBC announcement, I keep seeing discussions about how to
make the abbr's title attribute more accessible, and I keep wondering,
why are we so stuck on using abbr at all? I read the justification for
it, and it makes sense, but it's hardly the only way to go, so I'd
like to take a different approach and see what you make of it.

Many sites I've seen include daily archives, whether they be of
events, blog posts, new links, whatever. Pages including lists of such
events, or just the detail of a single event, will usually link to
that daily archive. The key is that that URL for the daily archive is
typically in just one of the two following formats:

* /2008/06/30/
* /2008/jun/30/

Call me crazy, but that looks as much like a machine-readable date
format as any I've ever seen. Better yet, the first form is completely
internationalized already, so it doesn't rely on NLP or anything. The
second form is also common, though, so it seems like an allowable
alternative (but maybe that's just because I use that form myself).
Links of this form could either use a class, as is currently done for
the abbr tag, or use something like rel="date", since it's fairly
similar to the rel-tag format. Also like rel-tag, it would look at the
*end* of the URL only. If someone had a link like
/weblog/2008/jun/30/, that would work just the same as
/corporate/public/events/2008/06/30/.

If microformat dates used URLs in links, rather than the titles of
abbreviations, the data would be just as visible as the rel-tag
pattern, wouldn't have "machine data" presented to users as standard
content, allows for flexible human-readable presentation (since it
could just be ignored), and has the added benefit of encouraging daily
archives on those sites that might not currently implement them. (And
yes, I realize that the "benefit" of daily archives is debatable.
Please don't bother, since that debate is irrelevant to this
discussion.)

Of course, that still leaves the issue of time, but times are much
easier to parse automatically than dates, as data formats are far
fewer and much more recognizable. This is the one area of the link's
content that I'd suggest to be parsed, so that times become part of
the link. Essentially, there are two dominant formats for time:

* 13:23
* 1:23 pm

Given the need for internationalization, I'd suggest that a 24-hour
time be assumed, if no suffix is given. The "pm" we use in English is
common, but isn't necessarily so throughout the world, so it should be
an available alternative, but not the assumed standard. It should be
acceptable with or without periods, and perhaps it could even look
only at the first letter, so even just "a" or "p" could be allowable.
Of course, that means that anyone who publishes a 12-hour time without
a suffix will cause all of their events between noon and midnight to
be misinterpreted, but that could happen even without microformats.

In summary, I'd like to offer a couple options for displaying dates,
though I'm not sure which one is "best". Feel free to discuss, comment
on, improve, or outright deny them. Consider some possible
representations of the following: June 30, 2008 at 1:00 pm.

* <a class="dtstart" href="/2008/06/30/">June 30, 2008 at 1:00 pm</a>
* <a class="dtend" href="/events/2008/jun/30">13:00</a>

To add a bit more flexibility, I think it might be better still to
include a new rel-date pattern, which would specify the date as a URL,
as well as a class which defines the entire date/time combination.
Such an approach would allow for a more more usable markup structure,
such as:

<span class="dtstart"><a rel="date" href="/2008/jun/30/">June 30</a>,
from 1:00p</span> to <span class="dtend">2:00p</span>

If nested formats aren't allowed, I'll concede that, but I think
there's value in allowing the time to be separate from the link, since
the destination won't be tied to a particular time, but rather just
the day. Also, note that in the event that a dtend doesn't specify a
date, it should be assumed to be the same as dtstart, which must
always specify a date.

Also, before I get accused of not thinking about it, I don't know yet
how would be best to deal with time zones. On one hand, I think they
could be parsed as part of the time format above, but I don't know if
it's any more accessible to include "-0500" in the content, or if the
names or abbreviations of time zones are standardized enough
(especially internationally) to work well. It's also possible to store
just the time zone as an offset in some meta tag on the page itself,
providing a hint for microformat parsers on how to process times
within that page. I have no suggestion on that issue, but I do
acknowledge that it's left undefined at the moment. Suggestions are
welcome.

-Gul