How to translate between windows and IANA timezones in java

Question

I need to translate between IANA timezone & windows timezone & vice-versa. There is another question reported: How to translate between Windows and IANA time zones?

It specifies that Noda time library can be used in .Net

Do we have any library to be used in Java? Or any other utility to be used in java?

Heaton

There's already code.google.com/p/java-time-zone-list but that's a few years old - I suspect it hasn't taken the new CLDR format for Windows time zones. But basically that's what you want - the data from CLDR. – Bracketing

You may have to write this yourself by going through similar logic against the CLDR data directly. – Circumgyration

Answer 1

I finally had to make my own implementation. The windowsZones.xml needs to be updated for plenty of missing timezone entries. I'm not publishing the updated file as there are many timezones where there is no perfect match between Windows offset & IANA offset.

Also, as for one Windows timezone there could be multiple IANA timezone. So, i had to make implementation to choose best suitable according to other information available like geography of user(address) etc.

With this, I'm just using the windowsZones.xml to get IANA timezone from Windows timezone & vice-versa.

Heaton

Answer 2

This may be what you need, but I don't know if it will work for all your use cases:

for (String tzId : TimeZone.getAvailableIDs()) {
  TimeZone tz = TimeZone.getTimeZone(tzId);
  if (tz.getDisplayName(Locale.ENGLISH).equals("Eastern Standard Time")) {
    System.out.println("tz = " + tzId);
  }
}

Actomyosin

Java's English display names are from CLDR (I think). They will not match up 1::1 with Windows time zone identifiers. – Circumgyration

Yes, Java's English display names don't match 1::1 with Windows time zone Ids. – Heaton

@MattJohnson-Pint In Java 9, the Unicode Consortium's Common Locale Data Repository (CLDR) became the default for locale information including time zone names. See JEP 252: Use CLDR Locale Data by Default. – Land

Answer 3

I have implemented support for Windows zones in my Java-library Time4J. The last version v4.2 is also interoperable with Java-8 so it is easy to convert all basic Time4J-types to java.time-equivalents. For example recognizing Windows zones as strings is possible in constructing as well as during parsing:

  // conversion Windows to IANA
  WindowsZone wzn = WindowsZone.of("Eastern Standard Time");
  TZID winzone = wzn.resolveSmart(Locale.US);
  System.out.println(winzone.canonical()); // WINDOWS~America/New_York

  // usage in timezone calculation
  Timezone tz = Timezone.of(winzone);
  System.out.println(Moment.UNIX_EPOCH.toZonalTimestamp(winzone)); // 1969-12-31T19

  // usage in parsing and formatting
  ChronoFormatter<Moment> f =
    ChronoFormatter.ofMomentPattern(
      "MM/dd/uuuu hh:mm a zzzz", PatternType.CLDR, Locale.US, winzone);
  Moment pacificTime = f.parse("07/17/2015 02:45 PM Pacific Standard Time");
  System.out.println(f.format(pacificTime)); // 07/17/2015 05:45 PM Eastern Standard Time

As you can see, a locale Information is necessary to map a Windows zone like "Eastern Standard Time" to an Olson/IANA-identifier like "America/New_York". The underlying data and mapping informations are taken from CLDR.

The reverse way from IANA to Windows might be done this simple way:

String iana = "America/New_York";
String winzone = "WINDOWS~" + iana;
NameStyle dummy = NameStyle.LONG_STANDARD_TIME; // does not really matter
String name = Timezone.of(winzone).getDisplayName(dummy, Locale.US);
System.out.println(name); // Eastern Standard Time

However, this reverse conversion might not work for all iana-identifiers because Windows only supports a very simplified subset of timezones compared with IANA-TZDB. I also think that the reverse way is hardly used in practice. Users should rather work with IANA-timezones by default and only use Windows timezones if that is the (unavoidable) input to handle (see first part of my answer).

Cornejo

It seems to be good option. The issue still continues for converting IANA to windows as for we have multiple IANA Ids for one Windows timezone Id. As i mentioned in my answer above, currently, I'm using windowsZones.xml & managing inter-conversions by maintaining map of IANA ID against Windows TX ID & vice-versa. – Heaton

"As you can see, a locale Information is necessary to map a Windows zone..." - why is that so? The data in unicode.org/repos/cldr/trunk/common/supplemental/… for example is non-localized and neither is support.microsoft.com/en-ca/help/973627/…. – Boast

@MarcelStör The unicode link you had given clearly shows how the mapping is localized, be aware of the territory-attribute in the xml-file which points to the ISO-code for country. – Cornejo

@MenoHochschild thanks for your feedback. Made me realize my comment was a bit imprecise, sorry. Again, referencing the XML...Let's take "Hawaiian Standard Time". I understand that based on the territory you get a different TZ identifier. However, for offset calculations and the like it's not relevant whether you use "Pacific/Rarotonga", "Pacific/Honolulu" or even "Etc/GMT+10", is it? – Boast

@MarcelStör Rarotonga and Honolulu have actually the same offset UTC-10, but their offset history is different for dates in the past, see the files for northamerica and australasia on the website of Paul Eggert, the maintainer of IANA-TZDB. – Cornejo

Answer 4

You can use ICU4j library (https://unicode-org.github.io/icu/userguide/icu4j/).

pom.xml (Maven):

<dependency>
  <groupId>com.ibm.icu</groupId>
  <artifactId>icu4j</artifactId>
  <version>74.2</version>
</dependency>

Then in Java:

import com.ibm.icu.util.TimeZone;

return TimeZone.getWindowsID("America/New_York");

Mingo