[Python-ideas] Date/time literals

[Guido van Rossum]

On Wed, Jun 2, 2010 at 5:45 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 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).

I'd be okay with immediate normalization in both of these cases as
well. Immediate normalization cuts off all concerns about unnormalized
datetimes, consistent comparisons, etc.

-- 
--Guido van Rossum (python.org/~guido)