[Python-Dev] PEP: New timestamp formats

[Victor Stinner]

> datetime.datetime
>
> - as noted earlier in the thread, total_seconds() 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