[whatwg] Expanding datetime

[Ian Hickson]

On Wed, 23 Apr 2008, Ernest Cline wrote:
>
> The range of valid datetime strings is a subset of those specified by 
> ISO 8601.  Most of the unused formats have been rejected on the grounds 
> of simplicity of parsing, but a format (I think added in ISO 8601:2004, 
> but it may have been earlier) offers a gain in utility that would not be 
> unduly complicated to implement. Datetime is current limited to years in 
> the range of 0000 - 9999.  Additional digits could be added to the year 
> and still keep the string a valid ISO 8601 string, provided that the 
> number to be added is agreed to and the added digits are always preceded 
> by either a + or -.  For example, if one digit is added, then the day 
> before 0000-01-01 could be represented as -00001-12-31.  From a 
> practical viewpoint, being able to specify dates before January 1, 1 BC 
> (Gregorian) would allow for historical dates not currently available to 
> be specified in markup of documents concerning history.  The Y10K 
> problem can also be pushed back by this, but is of only theoretical 
> importance.

Dates outside the near past and near future really aren't in any of the 
use cases for date types in HTML5 so far.

For far away dates, use cases almost always end up being far more 
complicated, requiring things like range support, vague date support (e.g. 
just the month and year, or just the year, or a range of days in a month 
and year), explicit calendar support, etc.

So supporting those dates really isn't a problem that we need to solve, at 
least as far as addressing the use cases put forth so far.

Note that supporting old dates gets especially dicey given that calendars 
changed to the Gregorian calendar at different dates in different 
countries, so you have to include geographic information as well to 
convert old dates into Gregorian-equivalent dates. This is really an area 
of complexity that we do not want to specify in HTML5.


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.


On Fri, 25 Apr 2008, Christoph Päper wrote:
> 
> What about, for instance, adjustable timelines at history websites or 
> virtual skies at astronomic sites?

Neither of these would likely use type=date. Timelines probably would 
rather use logarithmic year selectors (e.g. using type=range), and virtual 
skies for dates far away will typically use Julian dates (which are more 
like type=number step=any).


On Thu, 24 Apr 2008, Charles wrote:
> 
> Genealogy would seem to be another relatively popular use.

Genealogy's use of dates is far, far more complex and involved for old 
dates than anything type=date can do.


On Fri, 25 Apr 2008, Henri Sivonen wrote:
> 
> I think the questions are:
>  * Are there use cases for entering proleptic Gregorian dates before the
> Common Era in a Web form (<input type=date>)?
>  * Are there use cases for representing proleptic Gregorian dates before the
> Common Era in a way that moving the data to a calendar app (<time>)?
>  * Are there use cases for  annotating document modifications with proleptic
> Gregorian dates before the Common Era (<ins>/<del>)?
> 
> I think the answer to the ins/del case is "no". The future is intended 
> for tracking changes in computer documents, and all historical documents 
> have been migrated to computer documents in the Common Era.
> 
> I think the answer to the calendar at case is in "no". The calendar app 
> case is about planning future events. You don't need <time> markup when 
> writing about historic events before the Common Era--in particular, if 
> you write about events that are referred to by their Julian dates.
> 
> As for the form case, it seems implausible to me that sites about the 
> history of urban planning or ecology would require users to enter dates 
> that are more precise than to the year. In the case of sites about 
> historic events, it also seems implausible that users would be competent 
> to enter precise proleptic Gregorian dates for searching events that 
> occurred when the Julian Calendar was in use (or in other locales a 
> calendar that *looks* different, too).
> 
> To make calculations with the precision of a year, the user interface 
> could use a form field that takes a number and sidestep the issue of 
> converting the year two seconds or milliseconds.
> 
> The historic astronomy case seems awfully narrow to justify making 
> native date widgets deal with BCE dates.

I agree with all these points.


On Thu, 24 Apr 2008, Lachlan Hunt wrote:
> 
> Such dates do not need to be published on the web in machine readable 
> readable formats.  How often to do you need to book a flight, or add an 
> event to your calendar that far back in the past?
> 
> > ...The Y10K problem can also be pushed back by this, but is of only 
> > theoretical importance.
> 
> There are still 7992 years before we need to have a Y10K solution 
> implemented.  Thus we can safely leave it to to future generations to 
> solve.

It does seem somewhat unlikely that any of this will still be relevant in 
7000 years.


On Thu, 24 Apr 2008, Matthew Paul Thomas wrote:
> 
> On a museum's Web site, you might want to search its database of 
> antiquities for those from the Mauryan Empire. In an online 
> encyclopedia, you might want to find people who were alive at the same 
> time as Alexander the Great. On a genealogy site, you might want to 
> publish the family tree of the leaders of the Han dynasty.

But with type=date? Really?


On Thu, 24 Apr 2008, Ernest Cline wrote:
> 
> So the web is now used only for business?  And we'll be able to predict 
> exactly what uses users will want to make of it?

No, we don't have to predict. But we only have to design the language to 
handle the cases that we think are important.


On Thu, 24 Apr 2008, WeBMartians wrote:
>
> There's an historical precedent that argues in favor of expanding the 
> datetime string.
> 
> Many calendar utilities limit the date domain to the UNIX one. Thus, 
> entering an anniversary for a wedding that occurred prior to 1970 is the 
> "kiss-of-death:" there is no way to determine just which anniversary is 
> involved (silver anniversary, paper, ceramic...). A small item? Not to 
> the gift card and gift industries.
> 
> So an apparently trivial, supposedly non-business limitation had a big 
> effect.
> 
> Whether or not providing a means to specify dates before the Gregorian 
> Reform or before the beginning of the first millennium will have a 
> business effect is difficult to determine. One thing that can be said is 
> that the applications which would be enabled certainly won't exist if 
> the facilities are not present.
> 
> Currently, the extreme datetime values (as opposed to the strings) can 
> be specified in Javascript. Producing the corresponding datetime strings 
> from such values should be mandatory. That argues in favor of proper 
> "round trip" handling: the conversion of extreme datetime strings should 
> be available too.

I'm not convinced.

What would be helpful is examples of existing pages that use input 
controls that deal with dates that are not currently handled by the date 
time format in HTML5. That would help us determine what we actually need.



On Fri, 25 Apr 2008, Ernest Cline wrote:
> 
> These three formats are a subset of those suggested by the W3C datetime 
> note [1] which itself is a subset of the choices available under ISO 
> 8601.
> 
> The HTML 5 draft currently extends this to allow:
>  * leaving out the seconds (valid under the W3C datetime note)
>  * adding a decimal point and one or more digits for fractional seconds (valid under the W3C datetime note)
>  * specifying just the date (valid under the W3C datetime note)
>  * specifying just the time (valid under ISO 8601, but not the W3C datetime note)
>  * replacing the "T" separator between the time and date with whitespace (NOT VALID under ISO 8601)
>  * including some optional whitespace in some specific places (NOT VALID under ISO 8601)
> 
> Unless allowing the whitespace is needed to back standardize an existing 
> implementation's handling of <ins>/<del>, it should be removed from the 
> draft as it is not ISO 8601 compliant and complicates the job of the 
> parser, though I grant it does improve the human readability slightly.

I don't see a benefit here to blind adherence to 8601. The 8601 format is 
hard to read, allowing whitespace gets around this with very little change 
to the parsing requirements.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'