[microformats-discuss] International date formats

[Tantek Ç elik]

On 7/26/05 4:50 PM, "Sam Deane" <lists at elegantchaos.com> wrote:

> On 26 Jul 2005, at 17:02, Tantek Çelik wrote:
> 
>> Why not? (or rather, why do you consider it "resort"ing?)  As long
>> as the
>> markup is valid, there is something to be said for going with a simple
>> solution that works.  There is nothing inherently wrong with
>> javascript and
>> tool tips.
> 
> Sorry - maybe that sounded a bit harsh. There's nothing wrong with
> Javascript of course, but it would be nice if authors didn't have to
> add custom code to each page, or users install a plug-in of some sort
> on their browser, just to get locally formatted dates.

Yes, that's definitely in the "would be nice" category, but certainly not
required.


> I do think there's something wrong from a user interface point of
> view with having to roll over a date to get a tool-tip, just to see
> the locally formatted date.

No such requirement has been made.


> However, as has been pointed out, similar
> code could probably inject the local format back between the <abbr>
> tags, making the tool tip solution unnecessary.

Yes.


> Incidentally, I think it might be preferable if the design pattern
> recommended using ISO8601 dates between the <abbr> tags as well as in
> the title attribute (maybe using a space instead of a "T" between the
> tags).

Absolutely not.  We cannot ask that of content publishers.

The reality is, content publishers are *already* publishing their dates and
times however they want, and seems most natural to their audience, to their
context.

One of the principles of microformats is to adapt to current behaviors, and
*minimize* the changes we ask of publishers, in order to lower the barrier
to adoption as much as possible.

If you look at how people naturally talk about events, sometimes just
mentioning times and relative days like "today", "tomorrow", "Friday", it
quickly becomes obvious that there is a need for seamlessly allowing folks
to markup such human abbreviations for date and time with some embedding of
an absolute datetime that is reasonably easy for machines to parse, while
still remaining reasonably human verifiable.  The current <abbr> microformat
design pattern satisfies these objectives.


> This may not be quite as readable as the author's chosen
> "human-friendly" representation, but it does have the advantage of
> being fairly unambiguous,

Not an objective.

It is futile to try to get all authors/publishers to write their prose
unambiguously.

> I can see that there will be cases where the date
> needs to be specified more informally, so ISO8601 wouldn't be
> appropriate,

This is the 99% case.  Way more than even 80/20.

> but there are also lots of cases where the exact
> representation chosen doesn't matter very much,

I've yet to see this actually.  From a human readability standpoint, the
visible representation is very important.

> I am speaking as a Brit who is easily (and often) confused by
> Americans writing the month before the day with no other context to
> indicate that I'm reading American and not English!

Unfortunately, nothing we do will be able to solve the problem of different
cultures writing dates differently in their prose.

The best we can do in the short/medium term is adapt to various customs, and
provide a way for the ISO8601 date time to be closely bound to the visible
date which is culture-specific.

Thanks,

Tantek