[Python-Dev] PEP: New timestamp formats

[Nick Coghlan]

On Fri, Feb 3, 2012 at 10:21 AM, Victor Stinner
<victor.stinner at haypocalc.com> wrote:
> I updated and completed my PEP and published the last draft. It will
> be available at:
> http://www.python.org/dev/peps/pep-0410/
> ( or read the source: http://hg.python.org/peps/file/tip/pep-0410.txt )
>
> I tried to list all alternatives.

Looks pretty good to me, just a few comments in regards to the
descriptions of the alternatives (I'm not advocating for any the
rejected options any more, since I'm happy with the current proposal,
but the PEP should be clear on our reasons for rejecting them):

decimal.Decimal
- using this by default *was* considered, but rejected due to the
bootstrapping problem (decimals are not builtin) and the compatibility
problem (decimals do not play nicely with binary floats)
- the chosen API also relates to the bootstrapping problem - since
decimal.Decimal is passed in to the API directly, the builtin modules
don't need to perform their own implicit import to get access to the
type

datetime.datetime

- as noted earlier in the thread, total_seconds() actually gives you a
decent timestamp value and always returning UTC avoids timezone issues
- 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")
- the complexity argument used against timedelta also applies

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

protocol
- should explicitly note that the "tuple of integers" format
discussion is relevant to any such protocol design
- explicitly note that this was rejected as being excessive given the
requirements, but that the specific syntax proposed allows this to be
introduced later if compelling use cases are discovered

boolean argument
- should note explicitly that this was rejected because we don't
generally like having argument *values* change return *types* (in
cases like 3.3's IOError, where values can determine the specific
*subclass* created, there's still a common parent type).



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