[Python-ideas] Date/time literals

[Alexander Belopolsky]

On Tue, Jun 1, 2010 at 12:36 PM, Guido van Rossum <guido at python.org> wrote:
> On Tue, Jun 1, 2010 at 9:28 AM, Mark Dickinson <dickinsm at gmail.com> wrote:
..
>> For the first, it would prevent tuples corresponding to valid UTC
>> times (or local times) causing an exception in the datetime
>> constructor.  I don't have any specific use-cases, but it's not hard
>> to imagine passing a tuple from some external UTC-supporting source to
>> datetime.datetime.
>
> Imagined use cases are just that.

Developers writing generic libraries have to deal with imagined use
cases all the time.  If I write an rfc3339 timestamp parser, I cannot
ignore the fact that XXXX-12-31T23:59:60Z is a valid timestamp.  If I
do, I cannot claim that my parser implements rfc3339.  An application
that uses python datetime objects to represent time may crash parsing
logs produced in December 2008 on the systems that keeps time in UTC.

If all my application does is to read timestamps from some source,
store them in the database and display them on a later date, I don't
want to worry that it will crash when presented with 23:59:60.

Of course, allowing leap seconds in time/datetime constructor may be a
way to delay detection of a bug.  An application may accept
XXXX-12-31T23:59:60Z, but later rely on the fact that dt1-dt2 ==
timedelta(0) implies dt1 == dt2.   Such issues, if exist, can be
addressed by the application without replacing datetime object as a
means of storing timestamps.  On the other hand the current
restriction in the constructor makes datetime fundamentally
incompatible with a number of standards.

PS: I believe systems capable of producing 23:59:60 in timestamps are
already more common than those that don't use IEEE standard for
floating point values.  Nevertheless, CPython contains a lot of code
designed to deal with imagined deviations from IEEE 754.