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

Guido van Rossum guido at python.org
Tue Jun 5 15:45:34 CEST 2012

On Mon, Jun 4, 2012 at 5:51 PM, Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote:

On Mon, Jun 4, 2012 at 5:25 PM, Guido van Rossum <guido at python.org> wrote: ..

But I don't know what ticks() is supposed to do. """ .ticks(offset=0.0,dst=-1) Returns a float representing the instances value in ticks (see above). The conversion routine assumes that the stored date/time value is given in local time. The given value for dst is used by the conversion (0 = DST off, 1 = DST on, -1 = unkown) and offset is subtracted from the resulting value. The method raises a RangeErrorexception if the objects value does not fit into the system's ticks range. Note:On some platforms the C lib's mktime() function that this method uses does not allow setting DST to an arbitrary value. The module checks for this and raises a SystemError in case setting DST to 0 or 1 does not result in valid results. """ mxDateTime Documentation, <http://www.egenix.com/products/python/mxBase/mxDateTime/doc/#Toc293683804>

I agree that would be a step backward.

I am assuming we would create totimestamp() and utctotimestamp() that mirror fromtimestamp() and utcfromtimestamp(). First, with the introduction of timezone.utc, the use of utc... methods should be discouraged.

Speak for yourself. TZ-less datetimes aren't going away and have plenty of use in contexts where the tz is either universally known or irrelevant.

fromtimestamp(s,timezeone.utc) is better than utcfromtimestamp(); now(timezeone.utc)  is better than utcnow(); and dt.astimezone(timezone.utc).timetuple() is better than dt.utctimetuple()

No, they are not better. They are simply different.

The advantage of the first two is that they produce aware datetime instances.

Whether that really is an advantage is up to the user and the API they are working with.

The last example may appear more verbose, but in most applications, dt.astimezone(timezone.utc) is really what is needed.

So you think.

Since we trust the user with the latter we should trust them with the former.

This does not follow.  When you deal with non-monotonic functions, defining the inverse functions requires considerably more care than defining the original.  For example, defining sqrt(), requires choosing the positive root.  For arcsin(), you need to choose between infinitely many branches.   I don't think many users would appreciate a math library where sqrt() and arcsin() take an optional branch= argument, but mxDT's ticks() features this very design with its dst= flag.  Most users will ignore optional dst= and live with the resulting bugs.  We had several such bugs in stdlib and they went unnoticed for years.

That's why I don't recommend adding ticks(). But those math functions do exist and we need their equivalent in the stdlib. Users will have a need to convert their datetime objects (with or without tzinfo) to POSIX timestamps, and the one-liners from the docs are too hard to find and remember. While I agree that not every handy three lines of code need to become a function in the standard library, the reverse also doesn't follow: it just being three lines does not make it a sin to add it to the stdlib if those three lines are particularly hard to come up with.

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.

I think these definitions are both sufficiently unsurprising and useful to add to the datetime module.

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

More information about the Python-Dev mailing list