[whatwg] Expanding datetime
webmartians at verizon.net
Wed Jul 30 16:14:25 PDT 2008
[Warning: begin tirade, diatribe, fulmination, harangue, jeremiad, and/or philippic]
I can see arguments on both sides of the question:
+ Microformats and extra-UNIXian-epochs are needed and there are business cases
Hawkes-Lewis alludes to such with the Disney link
Read: "Copyright Issues"
- It's so painful as to require a document comparable to the entire HTML5 specification
Previous postings have commented on datetime strings and ISO-8601
and look at that awful mess I used, above, as an example
Strangely, there exists an argument for a "crippling" of capabilities. It goes like this:
The question then becomes, "Is the specification properly limited or ludicrous?"
I would claim that an epoch of 1970 (the traditional, UNIX epoch) is ludicrous just because so many luminaries started their existence before that moment (for example, "me" - ahem). On the other hand, I could understand a requirement that an epoch of no later than 1900, while limited, is at least "proper" (even in light of some locales' not adopting the Gregorian calendar until the 1930s).
Just don't hinder the needs-case for somebody building the JS files (I repeat myself, but I did warn that this would be tediously hortatory).
[end tirade - Thank you for your patience]
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Benjamin Hawkes-Lewis
Sent: Wednesday, 2008 July 30 16:29
To: Ian Hickson
Cc: 'WHATWG List'
Subject: Re: [whatwg] Expanding datetime
Ian Hickson wrote:
> On Thu, 24 Apr 2008, Henri Sivonen wrote:
>> How do proleptic Gregorian dates before the Common Era fit into any
>> of the use cases that states are used for in HTML?
>> Insertion and deletion dates are contemporary. Date form widgets are
>> meant for airline and hotel reservations and, hence, need to pick
>> dates from the near future. The time element is meant for
>> microformats, which means that it will be used for encoding current
>> or near-future events dates.
Microformats may also be used to mark up events that happened in the past and people who are dead. For example:
If HTML5 does not provide a way to specify datetimes BC, then the microformats community would be left in the boat they're already in of trying to fudge markup to encode datetimes BC. Little gained, really.
Regardless of what elements are added to HTML5, I believe HTML5 needs a simple extension point where microformats can insert machine-parsable equivalents and expansions of human friendly data. Data types are by no means limited to those already covered by the HTML5 proposals:
XHTML2 provides such an extension point with the (confusingly named) CONTENT attribute:
Such an extension point could meet the use-case of making datetimes BC extractable and also any use-case for far-future datetimes without requiring HTML5 to explicit specify calendar APIs for them.
DATA-* is not yet such an extension point, since it is only to be used for private scripts not public metadata:
Obviously, it would be /ideal/ if DATETIME could actually handle a range of dates useful for educational and research purposes as well as social networking and business and if schoolkids and academics didn't have to fall back on extension points and homebrew code, but I accept that it would inevitably be more work to spec and probably for user agent developers to ultimately implement.
More information about the whatwg