[Python-Dev] PEP: New timestamp formats

[Jeffrey Yasskin]

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.