[Python-Dev] Issue 2736: datetimes and Unix timestamps

[Guido van Rossum]

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