[Datetime-SIG] PEP-431/495

[Akira Li]

Carl Meyer <carl at oddbird.net> writes:

> On 08/27/2015 12:59 PM, Alexander Belopolsky wrote:
>> Dealing with simple time strings like this should really be one step:
>> 
>>>>> ts = '2004-10-31 01:15 EST-05:00'
>>>>> dt = datetime.strptime(ts.replace('EST', '').replace(':', ''),
>> '%Y-%m-%d %H%M %z')
>>>>> print(dt)
>> 2004-10-31 01:15:00-05:00
>> 
>> It is unfortunate that we need to massage the input like this before
>> passing it to datetime.strptime().  Ideally,  datetime.strptime() should
>> have a way to at least parse -05:00 as a fixed offset timezone.
>> 
>> However, this problem has nothing to do with PEP 495.  Once you have the
>> UTC offset - there is no ambiguity.  The other 01:15 would be
>>  "2004-10-31 01:15 -04:00." The EST part is redundant and is dropped
>> explicitly in my solution and not used in the solutions by Tim and Guido. 
>
> I don't think that's true; it's not entirely ignored in Tim and Guido's
> solution, and your solution gives subtly different results. A datetime
> with a fixed-offset -0500 tzinfo and a datetime with a tzinfo that knows
> it is "US/Eastern" may represent the same instant, but they are
> semantically different. That difference could reveal itself after some
> arithmetic with the datetime (because in one case the tzinfo's utcoffset
> might change after the arithmetic, and in the other case it wouldn't).
> (Of course if it's a pytz timezone the offset wouldn't change until
> after a `normalize()`, but that's not necessarily true of any tzinfo
> implementation.)
>
> Guido and Tim don't provide code to parse "EST-05:00" to "US/Eastern",
> but their solutions both rely on assuming that knowledge. Tim said so
> explicitly: 'where you knew "EST" meant US/Eastern'

EST was ambiguous in the past [1]. But now the pytz code from the answer
returns a single utc offset and many timezones that use EST
abbreviation.

Obviously, even if the corresponding regions have the same utc now; it
doesn't mean that they use the same rules e.g., DST transitions may
occur at different time in different timezones that have the same utc
offset now.

Even if the timezones use the same rules now; they might have used
different rules in the past and they may use different rules in the
future. Europe is a good example.

Even if you know the zone id such as Europe/Moscow; different tzdata
versions may provide different rules for the same region i.e., if you
convert the time to UTC for storage then it is not enough to save the
zone id, to restore the same local time in the future.

The timezone abbreviation may be ambiguous by itself e.g., if
tzname='CST' then the code [1] produces 3 different utc offsets for the same
time (the corresponding representative timezones are America/Havana,
US/Central, Asia/Shanghai).

[1]
http://stackoverflow.com/questions/13707545/linux-convert-timefor-different-timezones-to-utc