[Python-Dev] Issue 2736: datetimes and Unix timestamps (original) (raw)

Guido van Rossum guido at python.org
Tue Jun 5 17:07:06 CEST 2012

On Tue, Jun 5, 2012 at 7:19 AM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:

On Tue, Jun 5, 2012 at 3:45 PM, Guido van Rossum <guido at python.org> wrote:

For datetimes with tzinfo, dt.totimestamp() should return (dt - epoch).totalseconds() where epoch is datetime.datetime.fromtimestamp(0, datetime.timezone.utc); for timezones without tzinfo, a similar calculation should be performed assuming local time. The utctotimestamp() method should insist that dt has no tzinfo and then do a similar calculation again assuming the implied UTC timezone. It would be nice if utctotimestamp() also worked with datetimes that have tzinfo set to UTC.

Hm, but utcfromtimestamp() never returns a datetime that has a tzinfo (it doesn't take a tzinfo argument like fromtimestamp() does).

But if we want to do this, we should just say that utcfromtimestamp() with a datetime that has a tzinfo honors the tzinfo, always.

In fact, we might go further and define fromtimestamp() to do the same thing. Then the only difference between the two would be what timezone they use if there is no tzinfo. That's fine with me.

And while I don't think we really need it, if there are concerns that some other epochs may be useful, we could add an optional epoch argument.

No, that's hypergeneralization. People working with other epochs can write the three lines of code -- or they can add or substract a constant that is the difference between their epoch and 1/1/1970.

Alternate epochs just aren't that common (and where they are, the datetime module probably isn't what you want -- you're probably doing calendrical calculations using some other calendar).

-- --Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list