[Python-Dev] Store timestamps as decimal.Decimal objects

[Victor Stinner]

> If a callback protocol is used at all, there's no reason those details
> need to be exposed to the callbacks. Just choose an appropriate
> exponent based on the precision of the underlying API call.

If the clock divisor cannot be written as a power of 10, you loose
precision, just because your format requires a power of 10. Using
(seconds, floatpart, divisor) you don't loose any bit. The conversion
function using this tuple can choose how to use these numbers and do
its best to optimize the precision (e.g. choose how to round the
division).

By the way, my patch uses a dummy integer division (floatpart /
divisor). I hesitate to round to the closest integer. For example,
19//10=1, whereas 2 whould be a better answer. A possibility is to use
(floatpart + (divisor/2)) / divisor.

>> We may need more information when adding a new timestamp formats
>> later. If we expose the "internal structure" used to compute any
>> timestamp format, we cannot change the internal structure later
>> without breaking (one more time) the API.
>
> You're assuming we're ever going to want timestamps that are something
> more than just a number. That's a *huge* leap (much bigger than
> increasing the precision, which is the problem we're dealing with
> now).

I tried to design an API supporting future timestamp formats. For time
methods, it is maybe not useful to produce directly a datetime object.
But for os.stat(), it is just *practical* to get directly a high-level
object.

We may add a new float128 type later, and it would nice to be able to
get a timestamp directly as a float128, without having to break the
API one more time. Getting a timestamp as a Decimal to convert it to
float128 is not optimal. That's why I don't like adding a boolean
flag.

It doesn't mean that we should add datetime.datetime or
datetime.timedelta right now. It can be done later, or never :-)

> No, you wouldn't add a timestamp specific method to the Decimal class
> - you'd add one that let you easily construct a decimal from a fixed
> point representation (i.e. integer + fraction*10**exponent)

Only if you use (intpart, floatpart, exponent). Would this function be
useful for something else than timestamps?

> But this gets us to my final question. Given that Decimal supports
> arbitrary precision, *why* increase the complexity of the underlying
> API by supporting *other* output types?

We need to support at least 3 formats: int, float and <high resolution
format> (e.g. Decimal), to keep backward compatibilty.

> datetime, timedelta and so forth would be able to get everything
> they needed from the Decimal value.

Yes. Getting timestamps directly as datetime or timedelta is maybe overkill.

datetime gives more information than a raw number (int, float or
Decimal): you don't have to care the start date of the timestamp.
Internally, it would help to support Windows timestamps (number of 100
ns since 1601.1.1), even if we may have to convert the Windows
timestamp to a Epoch timestamp if the user requests a number instead
of a datetime object (for backward compatibility ?).

Victor