[Python-Dev] PEP: New timestamp formats (original) (raw)

Jeffrey Yasskin jyasskin at gmail.com
Fri Feb 3 20:32:48 CET 2012

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' clockgettime(), 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. stmtime), 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.

More information about the Python-Dev mailing list