W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2009

[whatwg] Historic dates in HTML5

From: Philip Taylor <excors+whatwg@gmail.com>
Date: Thu, 5 Mar 2009 13:34:20 +0000
Message-ID: <ea09c0d10903050534y4f1952e5g3fc6f3070cb37f49@mail.gmail.com>
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
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
Received on Thursday, 5 March 2009 05:34:20 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:47 UTC