[whatwg] Expanding datetime

We're in a situation, here, where the HTML specification is about to say "You can specify a value, but, maybe, just maybe, you cannot show that value" ... "Oh, yes, AND we're not even going to tell you when that 'maybe' is in effect!"

If you can spec a value, you should be able to present it. Imagine setting a Javascript integer to -123456789 but not being able to toString() it. Imagine setting a  background-color: Red; but not having it show (or show as a different color). Imagine the howling and complaining about that!

The generation of the proper datetime string is easy, technically. Yes, Apple, Microsoft, Mozilla and Opera will have to ensure that the values can be generated, if such test cases do not exist already.

The datetime string to value conversion is going to cause some more effort.

Can the standard state that datetime strings support ISO 8601:2004 and leave it at that? (just a thought)

At the very least, have a MINDate MAXDate (a la the C limits.h) constant.

-----Original Message-----
From: whatwg-bounces@lists.whatwg.org [mailto:whatwg-bounces@lists.whatwg.org] On Behalf Of Ernest Cline
Sent: Friday, 2008 April 25 13:09
To: Henri Sivonen; Charles McCathieNevile
Cc: WHATWG List
Subject: Re: [whatwg] Expanding datetime

-----Original Message-----
>From: Henri Sivonen <hsivonen at iki.fi>


>
>The historic astronomy case seems awfully narrow to justify making 
>native date widgets deal with BCE dates.

Native date widgets already need to deal with BCE dates at the DOM level as they are well within the range of a DOMTimeStamp.  In ECMAScript the range of years for which any time in the year can be represented is from 283,459 BCE to 287,398 AD.
What is being proposed is allowing a document to specify such times in the document without having to resort to scripting by expanding the range of values the datetime attribute can represent.

The draft is already proposing making changes to the existing HTML 4 specification of datetime by allowing only the date or the time to be given instead of the full date and time, so datetime is already being proposed to be changed, so the question therefore is not should we change datetime, but rather what other changes would be worth incorporating so as to avoid having to change datetime a second time.  
(For instance, since DOMTimeStamp uses a millisecond granularity, allowing datetime to specify milliseconds may be of use as well.)

Received on Friday, 25 April 2008 12:23:14 UTC