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

[Alexander Belopolsky]

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.