[whatwg] <time>

[Tab Atkins Jr.]

On Thu, Mar 12, 2009 at 3:48 PM, Robert J Burns <rob at robburns.com> wrote:
> Hi Tab,
>
> On Mar 12, 2009, at 12:51 PM, Tab Atkins Jr. wrote:
>
>> At this point, I think I'm in strong agreement with two points, that
>> of allowing negative years and of allowing a range.
>>
>> Allowing negative years is so trivial on the parsing side as to make
>> it somewhat ridiculous that it's not supported.  The use-cases for a
>> full year-month-day in BC times are fairly small, but they do exist,
>> and so for the nearly nonexistent cost of implementation I think we'd
>> be doing a disservice not allowing this.  (The uses for negative years
>> increase substantially if either ranges or lower-granularity dates are
>> supported as well.)
>
> The problem with adding support for BC is we need to supplement ISO 8601
> with another specification or our own normative criteria. I'm not speaking
> against that, I think it is worthwhile, but I just want to be clear about
> the problems. Non-normative portions of ISO 8601 imply that a zero year
> should also be included which is a controversial step. It may be better to
> include negative years, but not a zero year. Or to indicate that every
> non-positive year in ISO 8601 actually indicates a year-minus-one in the
> proleptic Gregorian calendar. In this way the simple leap year rules apply
> correctly to the years as they are used in the Common Era (and specifically
> BC/BCE).

I'm not much concerned about the debate over year 0; as has been
stated earlier in the thread, we're not date experts here.  As long as
we can get a clear answer out of ISO 8601, I'm happy with going with
that.  Whether or not to allow a year 0 is so far from an important
issue it isn't funny.  Worst case, the spec allows it but it
represents nothing.  I don't see this as a problem.

> I also think we could add support for longer years by requiring the use of
> hyphens whenever a year exceeds four digits. So 20090311 would be
> acceptable, but 10,000 years from now would have to be represented as
> 12009-03-11.

I'm not sure that is necessary to really worry about supporting.  But
hey, is it really necessary to add hyphens?  Is 120090311 ambiguous?
Is it just the lookahead issue?  (You'd have to read the entire date
string before you could be sure which part was year, month, and day.)

> Supporting Julian calendar dates also appears to be equally low-hanging
> fruit (or even lower) since such dates representations share everything in
> common with Gregorian dates (only the leap year rules are simpler and simple
> automated conversions before about 4AD are probably ill-advised).

This I still completely disagree with.  You want to write dates in the
Julian calendar on your page?  Feel free!  That doesn't affect
anything.  We're talking about handling a machine-readable form of
data.  I don't think there is any legitimate reason to add support for
multiple calendars in the timestamp.  It's bad enough that we have
*two* competing time formats (the current spec format and unix
timestamps) for encoding dates over the wire.  Just convert your date
into the supported timestamp format, then represent it however you
want within your page.

>> Supporting ranges seems to have a strong case for inclusion based on
>> the current dates.  As Charles says, it's relatively common for
>> current calendar events to take place over more than one day.  Making
>> time apply only to single days renders us incapable of marking this up
>> in a machine-readable way, which means that many common, current,
>> real-world events can't be automagically imported into a calendar app
>> appropriately.  The only possible current workaround, marking up the
>> start and end dates, is *far* from optimal.
>>
>>
>> (Supporting ranges would also give us support for lower-granularity
>> dates automatically, though in a slightly less convenient to author
>> manner.)
>
> I agree. We should support ISO 8601 encoded ranges.

Yeah, I'm not sure what the specifics of the various possible ways to
encode ranges are.  I just see that encoding them is something that
will be useful to authors *right now* in all the use-cases currently
established for <time>.  I would prefer going with ISO 8601 simply
because it's already established.

~TJ