Author Alexander.Belopolsky
Recipients Alexander.Belopolsky, Neil Muller, amaury.forgeotdarc, andersjm, belopolsky, catlee, davidfraser, erik.stephens, guettli, hodgestar, jribbens, mark.dickinson, pitrou, r.david.murray, steve.roberts, tebeka, tim.peters, tomster, vivanov, vstinner, werneck
Date 2010-12-17.17:06:09
SpamBayes Score 2.3674e-10
Marked as misclassified No
Message-id <>
In-reply-to <>
On Fri, Dec 17, 2010 at 9:18 AM, R. David Murray <> wrote:
> R. David Murray <> 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 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.
Date User Action Args
2010-12-17 17:06:11Alexander.Belopolskysetrecipients: + Alexander.Belopolsky, tim.peters, jribbens, guettli, amaury.forgeotdarc, tebeka, mark.dickinson, davidfraser, belopolsky, pitrou, andersjm, catlee, vstinner, tomster, werneck, hodgestar, Neil Muller, erik.stephens, steve.roberts, r.david.murray, vivanov
2010-12-17 17:06:09Alexander.Belopolskylinkissue2736 messages
2010-12-17 17:06:09Alexander.Belopolskycreate