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

[Guido van Rossum]

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)