[Python-Dev] PEP: New timestamp formats

Gregory P. Smith greg at krypto.org
Fri Feb 3 22:09:22 CET 2012


Why is the PEP promoting the float type being used as the default on the
new-in-3.3 APIs that were added explicitly to provide nanosecond level
resolution that cannot be represented by a float?

The *new* APIs should default to the high precision return value (be that
datetime/timedelta or decimal).

-gps

On Fri, Feb 3, 2012 at 11:32 AM, Jeffrey Yasskin <jyasskin at gmail.com> wrote:

> On Fri, Feb 3, 2012 at 11:17 AM, Antoine Pitrou <solipsis at pitrou.net>
> wrote:
> > On Fri, 3 Feb 2012 11:04:14 -0800
> > Jeffrey Yasskin <jyasskin at gmail.com> wrote:
> >> On Thu, Feb 2, 2012 at 4:59 PM, Nick Coghlan <ncoghlan at gmail.com>
> wrote:
> >> > datetime.datetime
> >> >
> >> > - real problem with the idea is that not all timestamps can be easily
> >> > made absolute (e.g. some APIs may return "time since system started"
> >> > or "time since process started")
> >>
> >> I think this is an argument for returning the appropriate one of
> >> datetime or timedelta from all of these functions: users need to keep
> >> track of whether they've got an absolute time, or an offset from an
> >> unspecified starting point, and that's a type-like distinction.
> >
> > Keep in mind timedelta has a microsecond resolution. The use cases
> > meant for the PEP imply nanosecond resolution (POSIX' clock_gettime(),
> > for example).
>
> Yes, I think someone had noted that datetime and timedelta would need
> to be extended to support nanosecond resolution.
>
> >> A plain number of seconds is superficially simpler, but it forces more
> >> complexity onto the user, who has to track what that number
> >> represents.
> >
> > If all you are doing is comparing timestamps (which I guess is most of
> > what people do with e.g. st_mtime), a number is fine.
>
> Sure. I don't think the argument for datetime is totally convincing,
> just that it's stronger than the PEP currently presents.
>
> > If you want the current time and date in a high-level form, you can
> > already use datetime.now() or datetime.utcnow() (which "only" has
> > microsecond resolution as well :-)). We don't need another way to spell
> > it.
>
> Whoops, yes, there's no need to extend time() to return a datetime.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120203/2505e53a/attachment.html>


More information about the Python-Dev mailing list