6

I have a date string that looks like this Tue Jul 19 2016 14:00:00 GMT-0700 (PDT). Is there a library or function that could do something like this?

print get_tz('Tue Jul 19 2016 14:00:00 GMT-0700 (PDT)')
'US/Pacific'
Alex Cory
  • 10,635
  • 10
  • 52
  • 62
  • Possible duplicate of http://stackoverflow.com/questions/3489183/how-can-i-get-a-human-readable-timezone-name-in-python – John Gordon Jul 20 '16 at 01:14
  • @JohnGordon: The difference is that your question is talking about the system timezone, whereas this is taking the timezone from a string. – zondo Jul 20 '16 at 01:19
  • You could try using regex and search for the word GMT, maybe? – ChaoticTwist Jul 20 '16 at 04:27

2 Answers2

3

I agree with @MattJohnson that you need to be very careful when parsing short timezone names to tzinfo objects. However, if you have a specific context where only one reading makes sense (e.g. you are parsing timestamps generated in the United States), you can use the tzinfos argument to python-dateutil's parse function.

Here is an example on how it is used:

from dateutil import tz
from dateutil.parser import parse

ET = tz.gettz('US/Eastern')
CT = tz.gettz('US/Central')
MT = tz.gettz('US/Mountain')
PT = tz.gettz('US/Pacific')

us_tzinfos = {'CST': CT, 'CDT': CT,
              'EST': ET, 'EDT': ET,
              'MST': MT, 'MDT': MT,
              'PST': PT, 'PDT': PT}

dt_est = parse('2014-01-02 04:00:00 EST', tzinfos=us_tzinfos)
# >>> dt_est.tzinfo
# tzfile('/usr/share/zoneinfo/US/Eastern')

dt_pst = parse('2016-03-11 16:00:00 PST', tzinfos=us_tzinfos)
# >>> dt_pst.tzinfo
# tzfile('/usr/share/zoneinfo/US/Pacific')
Graham
  • 7,431
  • 18
  • 59
  • 84
Paul
  • 10,381
  • 13
  • 48
  • 86
2

In general, you'll have to be careful about mapping time zone abbreviations to time zone identifiers. There's not a one-to-one mapping. For example, CST could be Central Standard Time, China Standard Time, or Cuba Standard Time.

Since you have both an offset and an abbreviation, you might be able to refine it a bit further, but you'll still have ambiguities. For example, if the string contained GMT+02:00 (EET), that could be any of the locations listed here, some of which use EET year-round, others of which use EET in the winter and EEST in the summer. Of those that use EEST, not all of them start and end at the same time.

Each variation creates a different time zone identifier. For example, Europe/Bucharest, Europe/Istanbul, Europe/Chisinau and Asia/Amman, all use EET and EEST, but all have slightly different transition dates or times.

Even when the current transitions align, they may have been different historically. For example, Europe/Athens and Europe/Helsinki may look the same at first, until you consider that Helsinki did not observe EEST in 1980.

These concerns will affect any library or function that attempts to resolve a time zone abbreviations and/or offsets to specific time zones, regardless of programming language.

Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575
  • So although the `zone abbreviations` remain ambiguous, I see them as more of a "nice to have" and not something to rely on for the correct time. Do you think it's possible to get the correct time every time by using the `timezone offset` and then just use the abbreviation at the end as just something there for nice formatting? – Alex Cory Jul 20 '16 at 19:25
  • All that you can definitively say is that the time zone offset and abbreviation shown are in effect at the specific time provided in the timestamp. You cannot say that the time zone offset or abbreviation applies to any other particular point in time unless you know the specific time zone through some other channel. – Matt Johnson-Pint Jul 20 '16 at 20:07
  • So basically we're sending the date in this form `Tue Jul 19 2016 14:00:00 GMT-0700 (PDT)` from the client. This gives us an accurate reading on the offset every time on the server because it gets sent from the client. So with that in mind, would this work the way I want it to? – Alex Cory Jul 20 '16 at 20:29
  • It gives you the client's *current* offset. That says nothing about what their offset *was* or *will be*. You get `-0700` in Pacific time right now, but after DST ends in November you'll get `-0800`. – Matt Johnson-Pint Jul 20 '16 at 20:39
  • Assuming you're talking about a web-browser as a client, you might consider one of the approaches [in this answer](http://stackoverflow.com/a/22625076/634824) to retrieve the actual time zone identifier (ex, `America/Los_Angeles`). You can then use this in Python with `pytz` or `dateutil`. – Matt Johnson-Pint Jul 20 '16 at 20:45