[whatwg] Dates and coordinates in HTML5

Tue Feb 24 10:59:13 PST 2009

It's back! It won't die! :-)

Although it can be argued that a standard should not consider the work required for implementation, many of the trade-offs in reference to times and dates do indeed take the present state of code into consideration.

One reason for not supporting BCE is a disagreement between historians and, say, astronomers, on how to represent the year immediately preceding year one. Is it year -1 (1 BCE) or year zero?

Currently, the text states that all dates and times since the beginning of the common era (0001-01-01 00:00:00Z) must be supported. Yes, the Javascript values can specify dates and times before this epoch. However, there is no way to interrogate the environment as to whether or not such values can be used with <time>. That would require much more work. Thus, the limitation of common era.

I'd love to see support for BCE and even for prolepsis and non-Gregorian calendars. ...but I do see the "no BCE" compromise as a workable one.
-----Original Message-----
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Andy Mabbett
Sent: Tuesday, 2009 February 24 13:42
To: WHATWG List
Subject: Re: [whatwg] Dates and coordinates in HTML5

In message <49A3E9B9.4090300 at lachy.id.au>, Lachlan Hunt <lachlan.hunt at lachy.id.au> writes

>Andy Mabbett wrote:
>> It seems to me that there are several outstanding, and overlapping, 
>>issues for <time> in HTML5, which include use-cases, imprecise dates, 
>>Gregorian vs. non-Gregorian dates and BCE (aka “BC“) dates.
>
>The time element was primarily designed to address use cases involving 
>contemporary dates.  It doesn't address non-Gregorian calendars or BCE 
>dates by design, as it is not really meant for historical dates.

Yes; and it is that narrow approach with which I take issue.

>Probably the most historical dates that it would really be suitably 
>optimised for are people's birthdates,

Why? Why are those dates more worthy of being semantically marked-up than, say, the date of the sailing of the Mayflower, of the birthdate of Caesar?

[...]
>These issues have all been discussed before, either here in the whatwg 
>or on public-html, and so I won't go into great detail.

I did make a point of saying:

        I've read up on what prior discussion I can find on the list;
        but may have missed some. I'll be happy to have anything I've
        overlooked pointed out to me.

>> First, though, I should like to make the observation that, while 
>>hCalendar  microformats are most commonly used to allow event details 
>>to be added  to calendar apps, and that that use case drove their 
>>development, they  should not be seen simply as a tool to that end. I 
>>see them, and hope  that others do, as a way of adding semantic 
>>meaning to mark-up; and  that's how I view the “time" element, too.
>>Once we indicate that the  semantic meaning of a string of text is 
>>date, it's up to other people to  decide what they use that for — "let 
>>a thousand flowers bloom", as the  adage goes.
>
>I think this is a philosophical difference in approach from that which 
>we used in developing the time element, and other features in HTML5.
>Semantics for the sake of semantics are not, and should not be, a 
>design goal.

I am not proposing semantics "for the sake of semantics"; I am showing that the semantics are already deployed, and that once deployed, the potential use cases are more varied than the current examples.

[...]
>While it may seem like a logical step to go from supporting those real 
>use cases, to supporting theoretical cases involving BCE dates, Julian 
>calendars, leap seconds and whatever else, this actually only ends up 
>introducing unnecessary complexity.

The use-cases I gave are not "theoretical".

Is the complexity really "unnecessary", or are we just putting off a difficult piece of work?

>> Use-cases for machine-readable date mark-up are many: as well as the 
>>aforesaid calendar interactions, they can be used for sorting; for 
>>searching...
>
>Yes, but the question is, are any of the use cases involving historical 
>dates really worth addressing with the time element?  If so, what are 
>those use cases and why are they significant enough?

The uses cases are in the paragraph you only quote partially, above. I think they are all worth addressing (indeed, I think it would be foolhardy not to), and I'm not alone in thinking so. How do you propose to measure their worth objectively?

>> hCalendar microformats are already used to mark up imprecise dates 
>> ("June 1977"; "2009"). ISO8601 already supports them. Why not HTML5?
>> Though care needs to be taken, it's even possible to mark up words 
>> like “today" with a precise date, if that's generated real-time, server-side.
>
>What are the use cases for marking up such imprecise dates?  Are people 
>using hCalendar for such purposes?

Yes, as I say in the text you quote; and on the sites I gave in my introduction (and unambiguously supported by the hCalendar specification and ISO8601). Use cases as above.

>> The issue of non-Gregorian (chiefly Julian) dates is a vexing one

>>It is not the job of the HTML5 working group to  solve this problem; 
>>but I think the group should recognise that at some  point a solution 
>>must be forthcoming. One way to do so would be allow  something like:
>>          <time schema="[schema-name]" datetime="[value]">[date in 
>>plain
>>         text]</time>
>
>Developing such a solution without having clear use cases and a good 
>explanation of why addressing those use cases is worthwhile, is not a 
>good use of our time.

Again, use cases have been given. Why do you feel that they are not clear?

>Even more so because you're trying to make room for a hypothetical 
>solution of marking up Julian dates that doesn't yet exist.

No; I'm proposing a solution which allows non-Gregorian date schemas to be used.

>> As for BCE dates, they're already allowed in ISO 8601 (since there 
>> was no year 0, the year 3 BCE is given as -0002 in ISO 8601). I see 
>> no reason why they should be disallowed in <time> elements in HTML5.
>
>Because allowing them requires additional effort, such as changes to 
>the parsing requirements, for which there is little to nothing gained 
>in practice due to a lack of compelling use cases.

Again: why are the use cases given not acceptable to you?

>> Coordinates
>>  Another abuse of ABBR in microformats for coordinates:
>>          <abbr class="geo" title="52.548;-1.932">Great Barr</abbr>  
>> Bruce and I agree that this could be resolved, and HTML5 usefully 
>> extended, by a “location" element:
>>          <location latitude="52.548" longitude="-1.932">Great
>>         Barr</location>
>
>I'm not familiar with the use cases for the geolocation microformat, 
>nor am I aware if there even are any.  So I will not comment on this.

There are many million 'Geo' microformats published in the wild, with support in several browsers/  plugins and on-line apps. Publishers include Google, Wikipedia and Flickr:

        <http://microformats.org/wiki/geo-examples-in-wild>

>> Using the “schema" attribute shown above, for non-Gregorian dates, we 
>> can extend that for Martian, Lunar (and eventually other bodies):
>>          <location schema="moon" latitude="52.548"
>>         longitude="23.47297">Sea of Tranquility</location>
>
>What's the use case for this?  Why would most people need to mark up 
>lunar co-ordinates?

For example: to allow such points to be easily found on maps, or in tools like Google Earth - the same as can be done presently for terrestrial coordinates, using "Geo" microformats.

Also of note is that NASA plans to begin constructing a permanent presence on the Moon (which will be referanceable by lunar coordinates; as will each of the places which they will then explore) in 2019 - that's three years before 2022 ;-)

>  Are astronomers really asking for such facilities to be included in 
>HTML?

The Astrogeology Team of the  U.S. Geological Survey have expressed interest. But astronomers are far from the only publishers of such data.

>  Would we really be addressing their needs by doing so?

Apparently so.

>> Now all we need to do is to work-around the abuse of ABBR for 
>> durations, in the draft hAudio microformat:
>>          <abbr title="PT3M23S">3 minutes 23 seconds</abbr>
>
>What's the use case?

That was a light-hearted comment, but see, for example, the duration properties in:

        <http://microformats.org/wiki/haudio>
and:
        <http://microformats.org/wiki/hrecipe>

More seriously, a more widely-scoped "measurement" element, capable of taking, for example, values of "duration", "length", "mass", "temperature", etc.; and a value; and perhaps a schema (defaulting to SI), would perhaps be more useful. Use cases are microformats, plus translation, automated conversion, sorting, etc.

--
Andy Mabbett