What Are the "Standard" Timezone Abbreviations

What are the standard timezone abbreviations?

What are the "standard" timezone abbreviations?

There are no standards for this. Time zone abbreviations are not officially coordinated by anyone. There are some used in the IANA TZDB, but a lot of those were just chosen at random. There is often debate on which abbreviations should be used. For example, look how many posts there were about Australian abbreviations in the list archives for April 2013.

Another list of time zone abbreviations can be found here. If you look closely, you'll see that many are ambiguous. For example, CST could be "Central Standard Time" (USA), "China Standard Time", or "Cuba Standard Time". EST could be "Eastern Standard Time" (USA), or "Eastern Standard Time" (Australia).

Some non-Australians might prefer AEST, but who's to say that A should be for Australia and not for America?

Another very common example, some people use HAST for Hawaii, while others use HST because they could care less about the Aleutian islands in Alaska (which is what the A is supposed to represent).

The point is that any list of time zone abbreviations, anywhere you find one, will be subjective and opinionated. There is no standard.

I am storing timezone by offset for an application using this dropdown:

Please don't do that. A time zone is not an offset, and there are many more than 24 of them. Please read the timezone tag wiki, especially the section titled "Time Zone != Offset".

From your comments:

I realize this now, however the rest of my application logic depends on it this way already, and I only have today to complete this, so no time to change it.

Then many errors will continue to be present in your application. You just can't do this reliably - not even if your app just runs in the US. It doesn't matter what language or platform you are on, any implementation that does this will have lots of conversion mistakes.

I'm ok with hardcoding these arrays, I just don't know what the popular zones are outside of the US, I figured such a list would already exist somewhere.

When it comes to time zones, you shouldn't hard-code anything. Time zone rules change all the time, because they are controlled by politicians in every country of the world. There are updates released multiple times per year to the IANA time zone database. On the PHP side, the PHP documentation makes clear what version currently available, and that updates are handled via PECL's timezonedb - which pulls it's data from IANA.

In regards to what's "popular" - that is highly subjective also. The zones in the TZDB are all there for one reason or another. The only place I know that has attempted to limit this is ActiveSupport::TimeZone from Ruby on Rails. They claim to have a "meaningful subset of 146 zones", which you can see in the MAPPING constant on that page. But they don't say by what process they've decided what is considered meaningful, and there are clear omissions. Unless you know for a fact where each and every one of your users will be located, I wouldn't attempt to decide what zones to limit to.

If what your after is something other that a dropdown list of all 578 zones in the TZDB, you can try one of these approaches:

Present two drop downs. The first to select a country. The second to choose a zone within that country. In PHP, you can see that when you call DateTimeZone::listIdentifiers, it accepts an optional $country parameter to filter the list.
A good example of this is in the settings for Google Calendar:
Use a map-based control so your user can select their time zone by location. There are many of these out there, but my favorite is this one for JavaScript.
For example, it might look like this:

Note that while it shows the TZDB abbreviation of EDT here - that is just used for a display convenience. Under the hood, you are selecting a value like America/New_York.

Ultimately, what you need to save for each user is their IANA time zone key, such as America/New_York. You cannot do correct time zone conversions with just a value of -5, because you don't have all of the rules of when it will switch to -4.

Update

One thing I didn't realize from your original post, but you clarified in comments, is that you are using this to choose a target event time zone. I guess I should have asked for context first. I was approaching this from the perspective of choosing a single time zone for your user, rather than a specific time zone for a particular event.

All you really need for an event to be at the correct moment is the offset for that moment. So you could use a dropdown like the one you showed in your question - but I would omit any zone names. It would litterally be a list of offsets from UTC-12:00 to UTC+14:00. It looks like you have identified already that some 30-minute and 45-minute offset exists also. You can verify your assumptions here if you like.

The general problem though, is that many people don't know what the offset should be. By putting a list with the standard offset for each zone name, you might mislead the user into picking the wrong offset. For example, they might be talking about a date in the summer that should fall into US Eastern Daylight Time (-4), but they pick the -5 selection instead because they see "Eastern". So removing the names will help.

If you go the way I originally suggested and have them pick an actual IANA time zone, that is going to work much better for many scenarios. However there is still one scenario you need to think about - how to handle ambiguous and invalid times. These happen during the DST transitions.

For example, I might select America/New_York, and pick a time of 1:00 AM on November 3rd 2013. There are two different instances of that due to the fall-back transition (one in EDT at -4 and another in EST at -5). So your app would need to check for this and ask the user which of the two they meant. Likewise, if I enter 2:00 AM on March 10th 2013, your app should tell me that this time does not exist in that zone (due to the spring-forward transition).

With either approach, when it comes to actually storing the event times, make sure you either store the date-time-offset combination, or you apply the offset to get a date-time that is at UTC. You don't want there to be any question about what actual moment in time is represented by the event.

Timezone Abbreviations

This is a tricky requirement, the best you can do is get the list of your choice and create a extension / helper method to get the abbreviation for the given TimeZoneInfo.

Once place to start is at http://www.timeanddate.com/library/abbreviations/timezones/ which has a version of list which covers the zones I am aware of.

The issue would be in selecting an appropriate abbreviation where more than one exists for a given timezone. For example UTC can be represented as UTC or WET (Western European Time) or WEZ (Westeuropäische Zeit) or WT (Western Sahara Standard Time).

You may want to agree with your stakeholders on the naming convention you are going to follow with the given choices.

Timezones abbreviations

A few things:

The list you pointed at is not the official list of Microsoft Windows time zones. It is a copy of a very old static list from Windows Embedded 1.1., which has long been deprecated. There presently is no actively maintained list of all Windows time zones on a Microsoft web page.
To get a list of Windows time zones, call TZUTIL /L on the command line. It will return the ID and display name of each time zone installed on the system.
If you look at the CLDR zone mapping file, you'll see that many Windows zones map to more than one IANA zone. If you simply map the Windows zone to the 001 "golden zone", you may end up picking an IANA abbreviation that doesn't apply for the user. Thus, if you take the approach you described (converting to IANA and taking the IANA abbreviation), be sure to take the country code into consideration as well when doing the mapping.

Also:

There is no official single list of time zone abbreviations anywhere, because time zone abbreviations are not standardized. Many of the abbreviations we might use in English don't necessarily apply to non-English speakers, and many time zones don't have abbreviations at all.
Even in English, many time zone abbreviations are contradictory or ambiguous.

Some examples of problematic time zone abbreviations:

Does CST mean Central Standard Time, Cuba Standard Time, or China Standard Time?
Does IST mean India Standard Time, Israel Standard Time, or Ireland Standard Time?
Should Hawaii use HST or HAST?
Should HNE (Heure Normale de l'Est) be used instead of EST (Eastern Standard Time) in Quebec, Canada since its official language is French?
What is the time zone abbreviation of Minsk, Belarus? You might think MSK, but that's offensive to some because that abbreviation is also commonly used for Moscow, Russia. Belarus has one time zone for the whole country, and they don't speak English there. IANA gives the abbreviation as simply the numeric UTC offset +03 (since mid 2011).

Because of the above problems...

There is no official list of time zone abbreviations for Windows time zones. Windows doesn't use them.
You might find some time zone abbreviations listed in CLDR data, and exposed with various libraries and APIs, but they only sparsely populated in the data set. CLDR has not been reliably collecting or maintaining time zone abbreviations.

Detect timezone abbreviation using JavaScript

If all else fails, you can simply create your own hashtable with the long names and abbreviations.

Getting timezone abbreviations in Swift

This is because time zone abbreviations are locale sensitive. IST only means India Standard Time (Asia/Kolkata) in India. In other parts of the world, it could mean Israel Standard Time, or Irish Standard/Summer Time. Here's a site that shows you the list of abbreviations. You can see for yourself how ambiguous they can be.

This is why abbreviation() takes into account the region of your phone, i.e. this setting:

Sample Image

abbreviation() will give you "IST" if your device's region is India. If your phone is somewhere else, it shows "GMT+5:30" because that is the safest, most unambiguous option.

If you want it to output IST no matter where your device is, you need to hard code this by creating a dictionary of time zone identifiers to abbreviations that you want. There is a built in abbreviationDictionary that goes the other way - abbreviations to identifiers. You can search it, and it will work for IST (Asia/Kolkata), but might not work for whatever other time zone that you are interested in.

let abbreviation = TimeZone.abbreviationDictionary
    .first(where: { $1 == TimeZone.current.identifier })?.key

and I'm not sure whether the contents of this dictionary will stay the same in future versions of iOS. Use it at your own risk.

Does ISO-8601 allow the time-zone abbreviation UTC rather than Z as the time-zone?

I have ISO-8601:2004, which according to Wikipedia is the latest edition. I do not see that it allows the use of UTC in place of Z, though it mentions "UTC" quite often in the specification.

Python: All possible Timezone Abbreviations for given Timezone Name (and vise versa)

I like unutbu's answer, which led me to the answer that worked for me. I have the locale of the user, so I found that I can use that to remove the ambiguity between time zone abbreviations.

In other words, this fixes the problem with the following:

In [242]: 'Asia/Shanghai' in tzones['CST']
Out[242]: True

In [243]: 'US/Central' in tzones['CST']
Out[243]: True

This function requires a two letter country code:

def GetTimeZoneName(timezone, country_code):

    #see if it's already a valid time zone name
    if timezone in pytz.all_timezones:
        return timezone

    #if it's a number value, then use the Etc/GMT code
    try:
        offset = int(timezone)
        if offset > 0:
            offset = '+' + str(offset)
        else:
            offset = str(offset)
        return 'Etc/GMT' + offset
    except ValueError:
        pass

    #look up the abbreviation
    country_tzones = None
    try:
        country_tzones = pytz.country_timezones[country_code]
    except:
        pass

    set_zones = set()
    if country_tzones is not None and len(country_tzones) > 0:
        for name in country_tzones:
            tzone = pytz.timezone(name)
            for utcoffset, dstoffset, tzabbrev in getattr(tzone, '_transition_info', [[None, None, datetime.datetime.now(tzone).tzname()]]):
                if tzabbrev.upper() == timezone.upper():
                    set_zones.add(name)

        if len(set_zones) > 0:
            return min(set_zones, key=len)

        # none matched, at least pick one in the right country
        return min(country_tzones, key=len)


    #invalid country, just try to match the timezone abbreviation to any time zone
    for name in pytz.all_timezones:
        tzone = pytz.timezone(name)
        for utcoffset, dstoffset, tzabbrev in getattr(tzone, '_transition_info', [[None, None, datetime.datetime.now(tzone).tzname()]]):
            if tzabbrev.upper() == timezone.upper():
                set_zones.add(name)

    return min(set_zones, key=len)

This returns the correct time zones for CST:

>>> GetTimeZoneName('CST','CN')
'Asia/Shanghai'

>>> GetTimeZoneName('CST','US')
'America/Detroit'

TimeZone name / abbreviation from offset

You cannot use the seconds offset from GMT, alone, to uniquely determine the timezone abbreviation. There is not a one-to-one correspondence between offsets and timezones.

This probably isn't going to be satisfying, but you can get a list of matching timezones by iterating through the knownTimeZoneIdentifiers and find a list of matching time zones:

let abbreviationsAndIdentifiers = TimeZone.knownTimeZoneIdentifiers
    .compactMap { TimeZone(identifier: $0) }
    .filter { $0.secondsFromGMT() == -28800 }

From there, you can use map to grab either abbreviation(for:), identifier or localizedName(for:locale:) to get PST, America/Los_Angeles or Pacific Standard Time for -28800, respectively. Obviously, the above may return a variety of different matches depending on the offset and time of year.

A few caveats for future readers:

Timezone abbreviations are not unique. See https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations and you’ll see the same three letter abbreviation mapping to completely different time zones. E.g. CST can mean “Central Standard Time” (in North America), “Cuba Standard Time” or “China Standard Time”.
Be wary about the fact that an offset from GMT of -28800 will result in different timezones depending upon the time of the year. E.g. -28800 will return one set of timezone matches in January and another set in July because of daylight savings. Consider using secondsFromGMT(for:), specifying the date, instead, to remove any ambiguity.

What Are the "Standard" Timezone Abbreviations