[Python-ideas] Date/time literals

[Alexander Belopolsky]

On Tue, Jun 1, 2010 at 12:17 PM, Guido van Rossum <guido at python.org> wrote:
..
> I expect this will cause a lot of subtle issues.

I will try to answer to those.

> E.g. What should
> comparison of an unnormalized datetime value to an equivalent
> normalized datetime value yield?

I am not proposing supporting arbitrary unnormalized datetime values,
only to allow seconds (0 - 60).  I am not proposing any notion of
"equivalent datetime" objects either.  POSIX will require that for  t1
= datetime(1985, 6, 30, 23, 59, 60) and t2 =datetime(1985, 7, 1, 0, 0,
0) time.mktime(t1.timetuple()) == time.mktime(t2.timetuple()), but
this does not mean that t1 and t2 should compare equal.

It is a more subtle issue, what difference t1 - t2 should produce.  I
think it can be defined as difference in corresponding POSIX times.

> How far will you go? Is
> datetime.datetime(2010, 6, 1, 36, 0, 0) a way of spelling
> datetime.datetime(2010, 6, 2, 12, 0 0) ?

I would not go any further than extending seconds to 0-60 range which
is common to many modern standards.

> How do you force
> normalization?

Normalization is never forced.  A round trip through POSIX timestamp
will naturally produce normalized datetime objects.

> Won't it break apps if the .seconds attribute can be
> out of range or if normalization calls need to be inserted?
>

Many standards require that seconds range be 0-60.  Applications that
obtain time from timetuples should already be prepared to handle this
range to be POSIX compliant.   Note that I do not propose changing
internal sources of datetime objects such as datetime.now() to return
dt.seconds == 60.  Therefore all extended range times will originate
outside of the datetime library.  Current application should already
validate such sources before passing them to datetime library.  Of
course an application that relies on constructor throwing an exception
for validation and then asserts that seconds < 60 will break, but this
can be addressed by proper deprecation schedule.  Maybe even starting
with enabling  extended seconds range with a from __future__ import.