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

Alexander Belopolsky alexander.belopolsky at gmail.com
Tue Jun 5 02:51:29 CEST 2012

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 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.

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

The advantage of the first two is that they produce aware datetime instances. The last example may appear more verbose, but in most applications, dt.astimezone(timezone.utc) is really what is needed.

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.

More information about the Python-Dev mailing list