What Timezone Abbreviation does Java use for your location?

I am writing timezone sensitive versions of several MATLAB date related functions (datenum, datestr, datevec, etc) for eventual posting to the FEX and have been using the abbreviations at the following link as my guide:

http://en.wikipedia.org/wiki/List_of_time_zone_abbreviations

Naturally, I would like my code (using the above) to be consistent with other s/w on the computer as far as timezone is concerned. Soooo ... I would like to invite the community to post the results of the following MATLAB code to this thread to confirm or refute that list. Specifically, I am looking to see that the timezone number and abbreviation reported by Java matches the abbreviation and number in the above list.

java.util.Date() % The date string display

-ans.getTimezoneOffset()/60 % the timezone offset from UTC

If you don't see your particular timezone already in the answers or you see a discrepancy with another answer already posted please post your results. Thanks! (I would do this myself ... but ... alas, I only live in one timezone)

Answer 1

[Matt Fig]

Everything looks kosher here:

>> java.util.Date() % The date string display

-ans.getTimezoneOffset()/60 % the timezone offset from UTC
ans =
Mon Feb 21 18:08:52 MST 2011
ans =
    -7

Answer 2

[James Tursa]

>> java.util.Date() % The date string display

ans =

Mon Feb 21 15:59:56 PST 2011

>> -ans.getTimezoneOffset()/60 % the timezone offset from UTC

ans =

    -8

Answer 3

[Paulo Silva]

Tue Feb 22 01:16:41 GMT 2011

0

Answer 4

[Walter Roberson]

Currently CST (-6), summer time is CDT (-5)

Answer 5

[Ellie]

Hey, My name is Ellie White and i have completed my java training with certification from SynergisticIT. It sounds like a simple question, but the answer is complicated. The time zone abbreviations supported by Java (whether we are talking the modern DateTimeFormatter or the troublesome and outdated SimpleDateFormat) are not defined by Java itself but by the locale data that Java uses. Complications include

• Java can be configured to take locale data from different sources. This means that setting the system property java.locale.providers when you run your program will change the set of abbreviations supported.
• The default locale providers were changed from Java 8 to Java 9. So running your program on a different Java version will give you a different set of supported time zone abbreviations.
• CLDR, the locale data that are the default from Java 9, come in versions. So every new Java version may come with a different set of supported abbreviations.
• Time zone abbreviations come in languages. So a formatter with French locale will support other abbreviations than a formatter with German locale, for example.
• Time zone abbreviations are ambiguous. So even if PST is a supported abbreviation, you don’t know whether it parses into Pitcairn Standard Time, Pacific Standard Time or Philippine Standard Time.

One way to get an idea: Run a program formatting dates at different times of year into a time zone abbreviation. Since many time zones use summer time (DST) and use a different abbreviation during summer time, you will want to try to hit a date in the summer and a date in the standard time of year for those zones.

System.out.println("java.locale.providers: " + System.getProperty("java.locale.providers"));

DateTimeFormatter zoneAbbreviationFormatter = DateTimeFormatter.ofPattern("zzz", Locale.FRENCH);

Instant northernSummer = Instant.parse("2019-07-01T00:00:00Z");

Instant southernSummer = Instant.parse("2020-01-01T00:00:00Z");

Set<String> supportedAbbreviations = new TreeSet<>();

for (String zid : ZoneId.getAvailableZoneIds()) {

ZoneId zone = ZoneId.of(zid);

supportedAbbreviations.add(northernSummer.atZone(zone).format(zoneAbbreviationFormatter));

supportedAbbreviations.add(southernSummer.atZone(zone).format(zoneAbbreviationFormatter));

}

System.out.println("" + supportedAbbreviations.size() + " abbreviations");

System.out.println(supportedAbbreviations);