[whatwg] Expanding datetime

[WeBMartians]

[Warning: begin tirade, diatribe, fulmination, harangue, jeremiad, and/or philippic]

At the very least, ensure that the range of times (dates, durations, intervals and times-of-day) and the granularity are well and rigorously specified. Ensure, also, that there is a Javascript mechanism to alarm, mechanically, when such element values exceed the specified envelope (I do not see such in the current text).

If the browser cannot handle a datetime string of "-0548-11-22 18:23:46,03276548901+3" (other-epochal, proleptic, locale-dependent and, I'm certain, annoying in several other respects), just make sure Javascript does something predictable and explicit.

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
		(http://en.wikipedia.org/wiki/Walt_Disney)
	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:

If a browser's Javascript is limited, JS files can support microformats, proleptic dates, Before-Common-Era dates, unique epochs and so on. However, the creation of such utilities will be hindered if the needs-case is nebulous. Failing to explicitly specify the HTML5 envelope will only increase that ambiguity ("Well, it works most of the time, so why bother?").

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] 

-----Original Message-----
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.
> 
> Right.

Wrong.

Microformats may also be used to mark up events that happened in the past and people who are dead. For example:

http://en.wikipedia.org/wiki/Walt_Disney

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:

http://microformats.org/wiki/machine-data

XHTML2 provides such an extension point with the (confusingly named) CONTENT attribute:

http://www.w3.org/TR/xhtml2/mod-metaAttributes.html#adef_metaAttributes_content

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:

http://www.w3.org/html/wg/html5/#custom

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.

--
Benjamin Hawkes-Lewis