[Python-Dev] PEP: New timestamp formats

Victor Stinner victor.stinner at haypocalc.com
Sat Feb 4 02:38:36 CET 2012

> Keep in mind timedelta has a microsecond resolution. The use cases
> meant for the PEP imply nanosecond resolution (POSIX' clock_gettime(),
> for example).

datetime.datetime and datetime.timedelta can be patched to support nanosecond.

>> 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.
> 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.

datetime.datetime is interesting with os.stat() if you want to display
the creation, modification or last access timestamp to the user. With
datetime.datime, you don't have to read the documentation to get the
reference date (Epoch for os.stat(), 1970.1.1) or the timezone (UTC
for os.stat()?). So datetime.datime contains two more information
(start date and timezone) than int, float or Decimal cannot store.

Supporting datetime.datetime just for os.start(), whereas
time.clock(), time.wallclock(), time.clock_gettime() and
time.clock_getres() fail for this format, is maybe a bad idea. There
is an exception: time.clock_gettime(time.CLOCK_REALTIME,
timestamp=datetime.datetime) would be accept and you can get a
timestamp with a nanosecond resolution... But datetime.datetime
doesn't support nanosecond currently :-)

The best reason to reject datetime.datetime is that it would only
"work" with some functions, whereas it would fail (with a ValueError)
in most cases.


More information about the Python-Dev mailing list