Carl Meyer carl@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-...