Re: [whatwg] <time>

On Sat, Mar 14, 2009 at 8:23 AM, Smylers <Smylers@stripey.com> wrote:

> only doing the simplest possible
> thing for now, acknowledging that that doesn't meet all desirable
>

> scenarios, and leaving everything else for HTML 6.
>
I'm proposing that we don't hold up that standard while trying to solve
> a hard problem.
>
> (I'm still in favour of people working on it to solve it.  And if there
> happened to be a consensus for a (partial) solution now I wouldn't be
> against including it.  But that isn't where we are.)
>
> Smylers
>


Wait. HTML 5 is a work performed over a decade, which we are only in the
middle. We are certainly no delaying anything here. HTML 6 would be another
decade of work. What we don't do now, we won't do for 15 years.

We don't have a consensus yet, and that is why I joined the debate. Because
I feel my opinion is important, although I feel people much more
knowledgeable then I am are going to show how wrong I am :P

I feel we are close to a 'partial' consensus, to reuse your term. Here is
what I feel most people agree on:

Use ISO 8601 with the following provisions:
- Allow all four digit years, positive and negative
- Allow lower granularity dates: 2009-03-14, 2009-03, 2009
- Allow ranges: 2009-03-01/2009-03-14
- Allow only extended format: 2009-03-14 (rather than 20090314) which will
help with simplification and future extensions

I'm not sure many have arguments against any of the above. Sorry if I missed
anything. I don't claim we have actually reached a consensus.

Here are items which we are debating over, with my opinion on these:

- Allow year 0000 or not?
Actually I don't see why it's important. I think it should be allowed.
Historians deny the existence of year 0, but astronomers use it. What if
year 0 is accepted as a valid date for the purpose of HTML, and then not
used by authors? It would become available for those authors who use year 0,
and ignored by others. Whats the implication? HTML parser does not perform
math over dates, it merely displays information based on what an author
instructed.

Here his the only debate I see over this:
ISO 8601:2000 and above suggest that year 0000 be used and be considered
year 1 BC, and then -0001 is 2 BC, etc. Most, I believe, will want year
-0004 = 4BC (and this is what I'd suggest).

- Allow 5 or more digit dates? Like year 10,000 or year 100,000 BC?
It's feasible: 10000-01-01, or -100000-01-01 (which is more likely to be
used with lower granularity I guess). I don't think this is going to give
parsers a greater complication.

- Allow non Gregorian calendars?
There are actually two debates on this issue. One is whether to allow other
calendars as the datetime attribute values, the other is to always have the
datetime attribute value specified as a Gregorian date while adding a new
attribute which would indicate what calendar is used for the content. I
would personally go against the use of any non Gregorian calendar at all,
since I do believe the use cases are too few. However if it is considered
that the use of non Gregorian is to be supported, I would go with the later
solution (allow non Gregorian as the content only, and have the datetime
attribute always defined as a Gregorian date), since that would not put much
complication on the parser (which does not have any calculation/conversion
to perform, leaving that to the author). The new attribute would then be
used by the browser to tell what calendar is used, but the datetime
attribute is still used to indicate to the user the Gregorian equivalent. I
do see too many problems with accepting non Gregorian as the value of the
datetime attribute: too many calendars are way incompatible (try to
represent a Mayan Long Count calendar),...

Those are pretty much the current debates, as I see it. Please feel free to
add anything I missed. My current recommandation would be that we try to
come to an agreement on current debates, rather than come up with more
debates. We have already determined that none of use are calendar experts
(and I have already proven I'm far from one), but I think we can come up
with something that would give enough flexibility to anyone without giving
much restrictions. One idea that comes to mind (if ever allowed by the
current HTML draft, I am no sure) could be to force parsers into a minimum
set of rules (i.e. accept at least 4 digits for years) while giving them the
freedom to decide whether or not to implement extended features (accept any
number of digits for years). Most popular browsers would probably implement
everything, while smaller ones (those with more restrictions, such as cell
phone browsers) could go with the minumem (and still cover 95% of use cases)
while leaving the extended, more demanding features (although I don't feel
my long year example is a good one to represent a 'demanding feature').