Re: [whatwg] <time>

Hi Smylers,

On Mar 14, 2009, at 7:23 AM, Smylers wrote:

> Indeed.  Spending more time on this may well yield something useful  
> and
> acceptable to at least most of those with opinions.  When that has
> happened the outcome can be incorporated in HTML 6.
> Andy Mabbett writes:

I think that if the original goal you stated is correct – to ensure  
that HTML5 makes space for HTML6 to do things correctly – there are  
certain things we should still consider doing now and including in  
HTML5.

For example allowing prefix, suffix or a supplemental attribute to  
encode a calendar for the ISO-8601-like date would be a very small  
change to HTML5 that would permit the right thing with HTML6.  
Basically we would be alerting HTML UAs that they may encounter such  
keywords and to ignore the ones they do not know. We might also  
require UAs to support the Gregorian (meaning ideally a complete  
proleptic Gregorian calendar) with HTML5. So this small change does  
not substantially increase the burden for implementors, but gives the  
future HTML spec writers more room to add new features. Then we simply  
need to add UA conformance criteria to differentiate the handling of  
dates without calendar keywords and those with a "Gregorian" keyword.

I also think there has been little substantive objections raised to  
extending the proleptic Gregorian calendar into BC years in an  
unambiguous fashion. The XSD datatypes recommendation[1] already  
points us in a sensible direction. If you or others have objection to  
that approach, then we have a dispute. However, I haven't seen a  
single message in this thread that raises an objection to that  
approach. David Carlisle did raise an objection to the representation  
of leap seconds in the XSD datatypes approach because it is difficult  
to calculate intervals involving leap seconds. However, I would say  
that that difficulty remains whether or not we allow authors to  
represent those leap seconds. For example even if we do not allow the  
representation of leap seconds, the problem of calculating the  
interval between: 1) 20081231t23:59:50 and 2) 20090101t00:00:05  
remains. The leap seconds are there whether we allow representation or  
not. So I don't think we really have much of a dispute over leap  
seconds as suggested in the XSD datatypes approach.

So I think the best way forward – one that makes room for the right  
thing in the future – is to:

1) Provide support for a complete proleptic Gregorian calendar as  
described in the note of XSD datatypes[1] (years with any number of  
digits and a clear definition of non-positive years);
2) Add support for an optional keyword prefix or suffix (such as  
"Gregorian_20090314t14:56:28") to open the way for handling of  
expanded representations in the future;
3) Require UAs to support values with the "Gregorian" keyword and with  
no keyword at all;
3) clearly describe UA conformance for how to interpret dates without  
a keyword (e.g., likely Gregorian dates, but might be errant Julian  
dates);
4) clearly describe UA conformance to treat those with keyword  
"Gregorian" as unambiguous Gregorian calendar dates.

These are all simple baby steps we can take with HTML5 that do not  
have to wait for HTML6. They are also suggestions that have not yet  
encountered substantive objections.

On point 3, let me pose the following question to the members of the  
WG. Consider yourself before encountering this entire thread on dates  
and alternate calendars and imagine you're drafting an HTML document  
that references the October revolution example we've been discussing  
so far. Might you be tempted to encode the date of this event using  
the 'time' element? Might you also be tempted to include the date  
within the 'datetime' attribute for metadata completeness (i.e.,  
"<time datetime="1917-10-25">October 25 1917</time>")? I think if you  
answer honestly, you'll answer yes to both questions. I know I would  
have made such an error before delving into the topic of alternate  
calendars. I think this is the type of error we can expect to see in  
HTML documents using the 'datetime' attribute as it is currently  
defined.

Therefore, I think we need to make some room for UAs to interpret such  
dates with some caution. Any 'datetime' value without a keyword is  
likely a Gregorian datetime value, but there may be errors and a  
specialized UA might take significant steps to heuristically determine  
where errors might occur (and allow user interaction to correct those  
errors). The ability to add a Gregorian keyword might also alert  
authors to the issue before encoding the date in the 'datetime'  
attribute. The 'Gregorian' keyword causes authors to pause and think  
"Is this indeed a Gregorian date?" Without that authors will tend more  
to mistake Julian dates for Gregorian dates.

This is an issue we can address now to open up space for HTML6 to fill  
in the gaps in the correct way and not have to come up with horrible  
hacks to correct our missteps. Are there any objections to these  
suggestions?

Take care,
Rob

[1]: <http://www.w3.org/TR/xmlschema-2/XSD#year-zero>
[2]: <http://lists.w3.org/Archives/Public/public-html/2009Mar/0315.html>