[Python-Dev] TZ-aware local time

[Guido van Rossum]

Let's agree to disagree. I don't have the time to argue any more but
you haven't convinced me.

On Mon, Jun 11, 2012 at 11:42 AM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> On Mon, Jun 11, 2012 at 1:01 PM, Guido van Rossum <guido at python.org> wrote:
> ..
>> Maybe the problem here is the *input*? It should be a POSIX timestamp,
>> not a datetime object.
>>
>
> No.  "Seconds since epoch" or "POSIX" timestamp is a foreign data type
> to the datetime module.  An aware datetime object with
> tzinfo=timezone.utc or a naive datetime object representing UTC time
> by convention is the datetime module way to represent absolute time.
> If I need to convert time obtained from an e-mail header or a log file
> to local time, I don't want to go through a  "POSIX" timestamp.  I
> want the obvious code to work correctly:
>
>>>> t = datetime.strptime(time_string, format)
>>>> local_time_string = datetime.localtime(t).strftime(format)
>
> (Note that the first statement already works in 3.2 if timezone
> information is compatible with %z format.)
>
> ..
>> Ok, I trust that LocalTimezone doesn't solve your problem. Separately,
>> then, I still think we should have it in the stdlib, since it probably
>> covers the most use cases besides the utc we already have.
>>
>
> I am not against adding LocalTimezone to datetime.  We can copy
> tzinfo-examples.py to datetime.py and call it the day.  However, this
> will not eliminate the need for the localtime() function.
>
>> PS. TBH I don't care for the idea that we should try to hide the time
>> module and consider it a low-level implementation detail for the shiny
>> high-level datetime module.
>
> I don't think I ever promoted this idea.  The time module has its
> uses, but ATM it does not completely solve the local time problem
> either.  See <http://bugs.python.org/issue1647654>.
>
>> .. Users
>> should be required to understand POSIX timestamps and the importance
>> of UTC before they try to work with multiple timezones.
>
> I disagree.  First, UTC and POSIX timestamps are not the same thing.
> I am not talking about leap seconds or epoch.  I just find this:
>
> $ TZ=UTC date
> Mon Jun 11 18:15:48 UTC 2012
>
> much easier to explain than this:
>
> $ TZ=UTC date +%s
> 1339438586
>
> There is no need to expose developers of e-mail servers or log
> analytics to 9-10 digit integers or even longer floats.  Second, UTC
> is only special in the way that zero is special.  If you write a
> function converting incoming time string to local time, you don't need
> to special case UTC as long as incoming format includes explicit
> offset.
>
>> And they
>> should store timestamps as POSIX timestamps, not as datetime objects
>> with an (implicit or explicit) UTC timezone.
>
> I disagree again.  At the end of the day, they should "store"
> timestamps in a human-readable text format.  For example,
>
> http://www.w3.org/TR/xmlschema-2/#isoformats
>
> Users who want an object that stores a POSIX timestamp internally, but
> presents rich date-time interface can use an excellent mxDateTime
> class.
>
> It is one thing to provide datetime.fromtimestamp() and
> datetime.timestamp() methods for interoperability, it is quite another
> thing to require users to convert their datetime instances to
> timestamp for basic timezone operations.



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