[issue2736] datetime needs an "epoch" method

Alexander Belopolsky report at bugs.python.org
Fri Dec 17 18:06:11 CET 2010


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Fri, Dec 17, 2010 at 9:18 AM, R. David Murray <report at bugs.python.org> wrote:
>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> Alexander, I agree with Velko in that it isn't obvious to me how the addition of localtime
> would answer the desire expressed in this issue.

Conversion of UTC datetime to time stamp is trivial:

EPOCH = datetime(1970, 1, 1)
def timestamp(t):
      return (t - EPOCH).total_seconds()

There are several reasons not to include this one-liner in stdlib
(other than it being a one-liner).

1. Different application may need different epoch and retained
precision depends on the choice of the epoch.

2. The code above works only on naive datetime objects assumed to be
in UTC.  Passing say a result of datetime.now() to it is likely to
result in a hard to find bug.

3. While it is not hard to extend the timestamp(t) code to cover aware
datetime objects that use fixed offset tzinfo such as those with
tzinfo set to a datetime.timezone instance, it is not well defined for
the "smart" tzinfo implementations that do automatic DST adjustment.
This is where the localtime (#9527) issue comes into play.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________


More information about the Python-bugs-list mailing list