[whatwg] Historic dates in HTML5

[Philip Taylor]

On Thu, Mar 5, 2009 at 12:56 PM, James Graham <jgraham at opera.com> wrote:
> Philip Taylor wrote:
>
>> and make sure their stylesheets use the selector ".time" instead of
>> "time", to guarantee everything is going to work correctly even with
>> unexpected input values.
>>
>> So the restriction adds complexity (and bugs) to code that wants to be
>> good and careful and generate valid markup.
>>
>
> On the other hand the python datetime class doesn't seem to support years <=
> 0 at all so consuming software written in python would have to re-implement
> the whole datetime module, potentially causing incompatibilities with third
> party libraries that expect datetimes to have year >= 0. This seems like a
> great deal more effort than simply checking that dates are in the allowed
> range before serializing or consuming them in languages that do support
> years <= 0.

The Python datetime class doesn't seem to support years > 9999 either,
which HTML5 allows. So Python consumers will already have to do "if
not year <= 9999: discard this time element since I'm not going to be
able to do anything with it", and it's easy for them to change that to
"if not 1 <= year <= 9999: ...". That seems less effort than adding
checks into the producers.

If there is a desire that any valid HTML5 date-time string should be
representable in Python's datetime class, then HTML5 should limit it
to 4 digits and refuse to parse anything longer. If so, why Python's
datetime in particular? The C++ Boost.Date_Time
(http://www.boost.org/doc/libs/1_38_0/doc/html/date_time/gregorian.html)
is apparently limited to "1400-Jan-01 to 9999-Dec-31". Perl DateTime
and PHP DateTime and Java joda-time
(http://joda-time.sourceforge.net/field.html) seem happy with a range
of millions of years in both directions. I'm not sure about any other
libraries. The range 1..9999 seems pretty arbitrary since it only
matches Python, and 1..inf doesn't match anything, so neither seems
particularly justified by implementations.

-- 
Philip Taylor
excors at gmail.com