9

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?

Community
  • 1
  • 1
Saurabhcdt
  • 1,010
  • 1
  • 12
  • 24
  • 2
    There's already https://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. – Jon Skeet Jul 16 '15 at 09:29
  • You may have to write this yourself by going through similar logic against the CLDR data directly. – Matt Johnson-Pint Jul 16 '15 at 17:49

3 Answers3

1

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);
  }
}
assylias
  • 321,522
  • 82
  • 660
  • 783
  • 1
    Java's English display names are from CLDR (I think). They will not match up 1::1 with Windows time zone identifiers. – Matt Johnson-Pint Jul 16 '15 at 17:48
  • Yes, Java's English display names don't match 1::1 with Windows time zone Ids. – Saurabhcdt May 17 '16 at 05:31
  • 1
    @MattJohnson-Pint In Java 9, the Unicode Consortium's [*Common Locale Data Repository (CLDR)*](https://en.wikipedia.org/wiki/Common_Locale_Data_Repository) became the default for locale information including time zone names. See [*JEP 252: Use CLDR Locale Data by Default*](https://openjdk.java.net/jeps/252). – Basil Bourque Jul 13 '20 at 23:39
1

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).

Meno Hochschild
  • 42,708
  • 7
  • 104
  • 126
  • 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. – Saurabhcdt May 17 '16 at 05:34
  • "As you can see, a locale Information is necessary to map a Windows zone..." - why is that so? The data in http://unicode.org/repos/cldr/trunk/common/supplemental/windowsZones.xml for example is non-localized and neither is https://support.microsoft.com/en-ca/help/973627/microsoft-time-zone-index-values. – Marcel Stör Sep 27 '18 at 08:14
  • @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. – Meno Hochschild Sep 27 '18 at 09:43
  • @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? – Marcel Stör Sep 27 '18 at 10:48
  • @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](https://github.com/eggert/tz/blob/master/northamerica#L708) and [australasia](https://github.com/eggert/tz/blob/master/australasia#L530) on the website of Paul Eggert, the maintainer of IANA-TZDB. – Meno Hochschild Sep 27 '18 at 11:57
0

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.

Saurabhcdt
  • 1,010
  • 1
  • 12
  • 24