I'm trying to map the values that come from the Front-End to ZoneId
class like this:
Optional.ofNullable(timeZone).map(ZoneId::of).orElse(null)
For most time zones it works fine, however, for some values Java throws exception:
java.time.zone.ZoneRulesException: Unknown time-zone ID: America/Punta_Arenas
However, it is a valid time-zone according to IANA: https://www.iana.org/time-zones
Zone America/Punta_Arenas -4:43:40 - LMT 1890
I was thinking about using offset for such time-zones (just to hardcode values), but I guess there should be more convenient way to solve the issue. Is there a way Java can handle that?
Other timezones that are not supported:
- America/Punta_Arenas
- Asia/Atyrau
- Asia/Famagusta
- Asia/Yangon
- EST
- Europe/Saratov
- HST
- MST
- ROC
My Java version: "1.8.0_121" Java(TM) SE Runtime Environment (build 1.8.0_121-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
I've tested with Java 1.8.0_121 and some zones are really missing.
The most obvious way to fix it is to update Java's version - in Java 1.8.0_131 all the zones above are available - except the 3-letter names (
EST
,HST
, etc), more on that below.But I know that updates in production environments are not as easy (nor fast) as we'd like. In this case, you could use the TZUpdater tool, which can update JDK's timezone data without changing Java's version.
The only detail is that
ZoneId
doesn't work with the 3-letter abbreviations (EST
,HST
and so on). That's because those names are ambiguous and not standard.If you want to use them, though, you can use a map of custom ID's.
ZoneId
comes with a built-in map:The problem is that the choices used in the
SHORT_IDS
map are - like any other choice - arbitrary and even controversial. If you want to use different zones for each abbreviation, just create your own map:The only exceptions for 3-letter names are, of course, GMT and UTC, but in this case it's better to just use the
ZoneOffset.UTC
constant.If you can't update your Java version nor run the TZUpdater tool, there's another (much more difficult) alternative.
You can extend the
java.time.zone.ZoneRulesProvider
class and make a provider that can create the missing ID's. Something like that:Create the
ZoneRules
is most the complicated part.One way is to get the latest IANA files and read them. You can take a look at JDK source code to see how it creates
ZoneRules
from that (although I'm not sure if the file that's inside JDK is in the exact same format as IANA's files).Anyway, this link explains how to read IANA's files. Then you can take a look at
ZoneRules
javadoc to know how to map IANA information to Java classes. In this answer I create a very simpleZoneRules
with just 2 transition rules, so you can get a basic idea of how to do it.Then you need to register the provider:
And now the new zones will be available:
There are other ways to use the provider (instead of registering), check the javadoc for more details. In the same javadoc there are also more details about how to properly implement a zone rules provider (my version above is very simple and probably it's missing some details, like the implementation of
provideVersions
- it should use the provider's version as a key, not the zone ID as I'm doing, etc).Of course this provider must be discarded as soon as you update the Java version (because you can't have 2 providers that create zones with the same ID: if the new provider creates an ID that already exists, it throws an exception when you try to register it).