[uf-discuss] datetime-design-pattern

[Tantek Ç elik]

On 11/1/05 9:48 AM, "Charles Iliya Krempeaux" <supercanadian at gmail.com>
wrote:

> Hello,
> 
> On 10/31/05, Kevin Marks <kmarks at technorati.com> wrote:
>> 
>> On Oct 31, 2005, at 10:59 PM, Charles Iliya Krempeaux wrote:
>>> 
>>> I skimmed the document, and it seems to imply that dates should always
>>> be encoded in YYYY-MM-DDThh:mm:ss±ZZZZ format.
>> 
>> Yes, this is a good thing.
>> 
>>> (Not sure if this has come up before, but) why not let the format be
>>> specified in the class attribute?  (With the default being iso8601.)
>>> For example:
>>> 
>>>     <abbr class="foo iso8601" title="20051031T23:01:31+0200">Halloween
>>> at 11:00:31 PM</abbr>
>>> 
>>>     <abbr class="foo rfc2822" title="Thu, 21 Dec 2000 16:01:07
>>> +0200">That day</abbr>
>> 
>> Why? What is served by adding an extra parameter and another huge
>> parsing load to support a non-localised obsolete date format?
> 
> The point wasn't really to support old obsolete date formats,

Good to hear.  Because those definitely are not 80/20.

> but to
> support new date formats in the future.

This is an important anti-pattern to recognize and point out:

 "to support new" ... "in the future"

usually means something unnecessary (and undesirable) overgeneralization,
which is specifically something that microformats as a whole avoids.

Specifically, the "in the future" part means that something *other* than a
real practical problem is being solved.

> Even iso8601 may become obsolete eventually.

Given that W3C (note-datetime, XML Schema), and IETF (RFC3339, Atom, etc.)
depend on ISO8601, we are in good company.

However, you are correct that use of ISO8601, as designed, with YYYY for the
year, will likely cause problems in the year 10000 and beyond (Y10K
problem).

Fortunately RFC 2550 has already addressed this problem.

 http://www.faqs.org/rfcs/rfc2550.html

Thanks,

Tantek