Add ability to convert datetime to Unix timestamp

[svisser]

I have a utility function to map a datetime to a Unix timestamp but this use case is common enough to have it in a library (preferably dateutil or pytz as these are very common Python datetime dependencies).

Searching online I can see that this comes up often enough that multiple approaches were coined. The first doesn't require additional dependencies, the second approach does depend on pytz:

>>> import calendar;
>>> calendar.timegm(d.utctimetuple())

>>> int((datetime_obj - datetime.datetime(1970, 1, 1, tzinfo=pytz.UTC)).total_seconds())

Is this something that would be useful in this library? The key thing is that neither of the above approaches expresses the idea in an "obvious" enough way to duplicate it across your codebase and a utility function would be desirable anyhow.

[marekrogala]

+1

[pganssle]

One problem here is that the semantics might be slightly unclear when you pass a naive datetime. I suppose we can just interpret naive times as local time.

[jbrockmendel]

One problem here is that the semantics might be slightly unclear when you pass a naive datetime.

Very much this. Especially in light of your next sentence, since my default assumption would be to go the other way and subtract naive datetime(1970, 1, 1).

[pganssle]

@jbrockmendel Yes, that would have been my preferred solution, but this would effectively be a backport of datetime.timestamp, which treats naive times as local. It would also do the inverse of what fromtimestamp() does:

>>> from datetime import datetime
>>> from dateutil import tz
>>> dt = datetime(2018, 1, 3, 12, 20, tzinfo=tz.tzlocal())
>>> (dt.astimezone(tz.tzutc()) - datetime(1970, 1, 1, tzinfo=tz.tzutc())).total_seconds()
1515000000.0
>>> datetime.fromtimestamp(1515000000.0)
datetime.datetime(2018, 1, 3, 12, 20)
>>> datetime.utcfromtimestamp(1515000000.0)
datetime.datetime(2018, 1, 3, 17, 20)

I think I'm going to put this decision off for a release after 2.7.0 because I'm not quite sure what we should do about "compatibility" methods like this. It might be that we add a new dateutil.compat module that backports functionality from the latest version of CPython so that you can write your code in a version-independent way.

[pganssle]

By the way, if we do decide to do a separate version of this (rather than a backport of datetime.timestamp) - like I did with utils.today(), we could possibly use my variants strategy to create two versions of this function: utils.timestamp(dt) and utils.timestamp.naive_utc(dt).

I would probably just vendor variants rather than add it as a dependency.

Still, in this case, I think it's probably best to do compat-only.