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

[Nick Coghlan]

On Tue, Jan 31, 2012 at 7:42 PM, Victor Stinner
<victor.stinner at haypocalc.com> wrote:
>> I think this is definitely worth elaborating in a PEP (to recap the
>> long discussion in #11457 if nothing else).
>
> The discussion in issues #13882 and #11457 already lists many
> alternatives with their costs and benefits, but I can produce a PEP if
> you need a summary.

PEPs are about more than just providing a summary - they're about
presenting the alternatives in a clear form instead of having them
scattered across a long meandering tracker discussion. Laying out the
alternatives and clearly articulating their pros and cons (as Larry
attempted to do on the tracker) *helps to make better decisions*.

I counted several options presented as possibilities and I probably missed some:

- expose the raw POSIX (seconds, nanoseconds) 2-tuples (lots of good
reasons not to go that way)
- use decimal.Decimal (with or without cdecimal)
- use float128 (nixed due to cross-platform supportability problems)
- use datetime (bad idea for the reasons Martin mentioned)
- use timedelta (not mentioned on the tracker, but a *much* better fit
for a timestamp than datetime, since timestamps are relative to the
epoch while datetime objects try to be absolute)

A PEP would also allow the following items to be specifically addressed:

- a survey of what other languages are doing to cope with nanosecond
time resolutions (as suggested by Raymond but not actually done as far
I could see on the tracker)
- how to avoid a negative performance impact on os.stat() (new API?
flag argument? new lazily populated attributes accessed by name only?)

Guido's admonition against analysis paralysis doesn't mean we should
go to the other extreme and skip clearly documenting our analysis of
complex problems altogether (particularly for something like this
which may end up having ramifications for a lot of other time related
code).

Having a low-level module like os needing to know about higher-level
types like decimal.Decimal and datetime.datetime (or even timedelta)
should be setting off all kinds of warning bells. Of all the
possibilties that offer decent arithmetic support, timedelta is
probably the one currently most suited to being pushed down to the os
level, although decimal.Decimal is also a contender if backed up by
Stefan's C implementation.

You're right that supporting this does mean being able to at least
select between 'int', 'float' and <high precision> output, but that's
the kind of case that can be made most clearly in a PEP.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia