[Python-ideas] Date/time literals

[Nick Coghlan]

On 02/06/10 03:28, Alexander Belopolsky wrote:
> 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.

The case for allowing a "60" value for seconds in the datetime 
constructor seems reasonable to me (i.e. prevent leap seconds from 
breaking date parsing), but I don't see the use case for delaying 
normalisation to a valid POSIX time.

If the constructor just converts the 60 to a zero and adds 1 minute 
immediately, then the chance of subtle breakages would be minimal and 
the current ValueError would be replaced by a far more graceful behaviour.

(Allowing 2400 hours just seems plain odd to me, but if it was adopted 
I'd suggest immediate normalisation be similarly applied in that case as 
well).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------