[Python-ideas] Date/time literals

[Marcos Bonci]

On 1 June 2010 13:17, Guido van Rossum <guido at python.org> wrote:

> On Tue, Jun 1, 2010 at 8:23 AM, Alexander Belopolsky
> <alexander.belopolsky at gmail.com> wrote:
> > On Tue, Jun 1, 2010 at 10:41 AM, Mark Dickinson <dickinsm at gmail.com>
> wrote:
> > ..
> >> As per the POSIX standard (IIUC), [datetime(1985, 6, 30, 23, 59, 60)]
> would be
> >> immediately converted
> >> to datetime.datetime(1985, 7, 1, 0, 0, 0) internally.  So the datetime
> >> object itself wouldn't support leap seconds, and would continue to use
> >> POSIX time;  only the constructor would support leap seconds.
> >>
> >
> > It is my understanding that POSIX mandates that mktime() function
> > normalizes the tm structure and therefore converts (1985, 6, 30, 23,
> > 59, 60, ...) to (1985, 7, 1, 0, 0, 0, ...).  It is not quite accurate
> > to say that tm structure is converted "immediately".  It is perfectly
> > legal to pass around non-normalized tm structures and have for example
> > utc2gps() function that would produce different values for Y-M-D
> > 23:59:60 and T-M-[D+1] 00:00:00.
> >
> > I would prefer a similar behavior for datetime constructor:
> >
> >>>> datetime(1985, 6, 30, 23, 59, 60).second
> > 60
> >>>> datetime(1985, 6, 30, 23, 59, 60).timetuple()
> > (1985, 6, 30, 23, 59, 60, ...)
> >
> > but
> >>>> datetime(1985, 6, 30, 23, 59, 60) - datetime(1985, 7, 1, 0, 0, 0)
> > datetime.timedelta(0)
>
> I expect this will cause a lot of subtle issues. E.g. What should
> comparison of an unnormalized datetime value to an equivalent
> normalized datetime value yield? 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) ? How do you force
> normalization? Won't it break apps if the .seconds attribute can be
> out of range or if normalization calls need to be inserted?
>
> The datetime module was written with "commercial" and everyday use in
> mind. In such use, there is no need to carry leap seconds around.
>
>
If this is really a design choice, then I guess my suggestions about
date+time literals and a unique/"official" date+time interpretation as
number really aren't good ideas. (Although I can't see why a
precise/scientific approach wouldn't be better than a commercial
one, as commercial applications often rely on precise standards.)

But I still don't understand why datetime.datetime.toordinal returns
an int that truncates time information. Is this deliberate?



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


-- Marcos --
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100601/73afd6c8/attachment.html>