1

I have a timezone information saved as "PST -8 0". I want to convert this into its equivalent timezone name e.g. America/Los_Angeles.

Is there any library or API which would be useful in this conversion? I am looking for a BASH command or a PYTHON API for this task.

I am not sure if this conversion is possible first of all and seeking your comments on the same.

AnilJ
  • 1,951
  • 2
  • 33
  • 60
  • Ok. It means that some of them can be converted, correct? In that case, what APIs are used to convert them? – AnilJ Dec 16 '15 at 00:39
  • Which part of the input do you want to "resolve", is it the "PST" part or the "-8 0" part? – Sebastian Dec 16 '15 at 00:39
  • PST. I don know how -8 0 influences it. Actually i have it in two forms. 1. PST8:0 and 2. PST 8 0. – AnilJ Dec 16 '15 at 00:42
  • here's [code example that enumerates all possible tzdata ids ("timezone names") that correspond to a given time zone abbreviation (such as `PST`) using the tz database](http://stackoverflow.com/a/13713813/4279). To adapt it for your case, in addition, filter the result on the utcoffset (`dt.utcoffset() == timedelta(hours=-8)` and dst (`dt.dst() == timedelta(0)`). btw, [@Matt Johnson's answer](http://stackoverflow.com/a/34315618/4279) should the accepted answer. – jfs Dec 16 '15 at 21:16

2 Answers2

4

While there may be some specific cases where you can do what you are asking, in the general case you cannot, for several reasons:

  • Time zone abbreviations can be ambiguous. For example, there are 5 different meanings for "CST". See Wikipedia's list of time zone abbreviations.

  • Time zone abbreviations are not uniform and consistent. Wikipedia's list will probably vary from other lists of abbreviations you may find elsewhere. In some places of the world, there is no abbreviation in use, and other places argue about what the correct abbreviation should be.

  • Time zone offsets do not fully represent a time zone. Pacific time is not -8. It's -8 in the winter and -7 in the summer. It changes for daylight saving time.

  • Many different time zone identifiers in the tzdb share the same offsets at certain point in time, and sometimes even share the same abbreviations. For the example you gave, the result could just as easily be America/Vancouver instead of America/Los_Angeles. In some cases, the various zones that could match will be significantly different for different points in time. Refer to the list of tzdb zones on Wikipedia, which includes their offsets.

Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575
2

Check out pytz for a Python API to the Olson timezone database.

As mentioned in the comments, the "PST" part is probably not reliable.

Using pytz you can bruteforce the problem, in a way. If we assume you want to resolve the numerical part of the input, and ignore whatever string precedes it, it could look something like this:

import pytz
import re
from datetime import datetime

def find_timezone_name(input):
    match = re.match(r'.*([+-]\d+) (\d+)', input)
    if match:
        offset = int(match.group(1))+int(match.group(2))/10.0
    else:
        raise ValueError('Unexpected input format')

    refdate = datetime.now()
    for tzname in pytz.common_timezones:
        tzinfo = pytz.timezone(tzname)
        tzoffset = tzinfo.utcoffset(refdate)
        if offset == tzoffset.total_seconds()/3600:
            return tzname
    return "Unknown"

print(find_timezone_name('PST -8 0'))

If you want to restrict the timezones to a specific list you can replace pytz.common_timezones with something else and/or apply some other type of logic if you have additional input data that would help your selection process.

Of course, you can adapt the regex to accommodate additional input variants.

Finally make sure you take in consideration the points mentioned by Matt Johnson in his answer to this same question.

Sebastian
  • 2,678
  • 25
  • 24
  • 2
    Nice attempt, but this matches strictly on the *current* offset. Since time zones can change offsets can for DST (and other reasons), you will get different results depending on *when* you run this code. See "Time Zone != Offset" in [the timezone tag wiki](http://stackoverflow.com/tags/timezone/info). – Matt Johnson-Pint Dec 16 '15 at 15:08
  • @MattJohnson I agree, I didn't have the time to delve into the "gotchas" but your answer covers them fairly well. In the end it is also closely related to what the exact requirement is. The requirement should indicate how these cases/scenarios/considerations are expected to be handled and the implementation can then change accordingly. I do feel however that the sample code should provide a good starting point. – Sebastian Dec 16 '15 at 18:00