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

Victor Stinner victor.stinner at haypocalc.com
Fri Feb 3 12:57:23 CET 2012

datetime.datetime

- as noted earlier in the thread, totalseconds() actually gives you a decent timestamp value and always returning UTC avoids timezone issues

os.stat() and time.time() use the local time. Using UTC would be completly wrong. It is possible to get the current timezone for time.time(), but how do you get it for os.stat() (for old timestamps)?

If we know exactly how to get the timezone, tzinfo can be filled. If there is no reliable way to get the timezone, it better to not fill the tzinfo field.

I don't see datetime without tzinfo as an issue.

Being unable to convert a datetime to an epoch timestamp is also not an issue: if you need an epoch timestamp, just use float or Decimal types.

- 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")

There is no such issue: each clock knows the start of the timestamp, or if the start is undefined (e.g. monotonic clocks). We can easily add a field to the interal structure describing a timestamp, and raise an exception of the start is undefined and user asked for a datetime object.

--

I don't see any real issue of adding datetime as another accepted type, if Decimal is also accepted. Each type has limitations, and the user can choose the best type for his/her use case.

I dropped datetime because I prefer incremental changes (and a simpler PEP is also more easily accepted :-)). We can add datetime later when most developers agree that datetime issues are no more issues :-)

tuple of integers

- option B doesn't force loss of precision, it's just awkward because you have to do a complicated calculation to express the full precision fraction in base 10 - option C only requires that the denominator be expressible as a power of some base. That's the case for all interfaces we're aware of (either a power of 2 or a power of 10).

If the denominator is coprime with 2 and 10, we cannot express it as a power of 2 or 10 without loss of precision. Example: denominator=3.

For option C, we have to use base=denominator and exponent=1 if a denominator is a prime number, or to not having to compute a log at runtime.

I don't see any real advantage of using base^exponent. When the denominator is unknown at build time: you have to compute the base and the exponent at runtime, whereas you will have to recompute base^exponent later to do the division. Why not simply storing the denominator directly? Even if you know the denominator at build time but is not a constant number, how do you compute a log2 or log10 using the compiler?

The only advantage that I see is for optimization for float if the base is 2 or for Decimal if the base is 10. But it looks like a minor advantage over drawacks.

clock() uses CLOCKS_PER_SEC (known at build time, depend on the OS), QueryPerformanceCounter() uses the CPU frequency or another frequency and is only known at runtime.

On Windows 7, QueryPerformanceFrequency() is 10^8 on my VM. I don't know if it is a constant. If I remember correctly, it is the CPU frequency on older Windows versions.

--

I updated the PEP for your other remarks.

Victor

More information about the Python-Dev mailing list