1

I have some code that reads a short timezone id from a record and passes it through this:

ZoneId.of(ZoneId.SHORT_IDS.get(place.getTz()))

I don't have control over what timezone ids are used, but I was under the impression that it would always be a legal short timezone id.

I guess the situation is that I needed to ask "a legal short timezone id according to WHICH STANDARD?" For instance, I just discovered that we have records with a timezone id of "AKST", which corresponds to Alaska standard time. The Java ZoneId class doesn't recognize this.

My workaround will be to manually construct the ZoneId for the timezone ids in the US that I know I will need to support, but which I know ZoneId does not support. My list is now one entry long. Are there any other "standard" (whatever that means) short timezone ids that ZoneId does not support?

David M. Karr
  • 14,317
  • 20
  • 94
  • 199
  • David server side should always be in UTC no? – Faraz Apr 08 '20 at 23:44
  • Thanks for replying, but I can't see how that is relevant, or even correct. – David M. Karr Apr 09 '20 at 00:04
  • David can you please take a look here: https://stackoverflow.com/a/1707934/4828463 – Faraz Apr 09 '20 at 00:21
  • I guess that convinces me that I can't really rely on a standard for the short ids. In any case, I discovered that I could search all the records for unique tz values, and AKST was the only outlier, so I can live with this. It is very unlikely new records with different timezones will be appearing, ever. – David M. Karr Apr 09 '20 at 00:27
  • The problem is not which ones are supported. You can build your own map instead of `SHORT_IDS` and put into it whatever you want. The problem is that some are ambiguous and/or not true time zones.If someone specifies MDT (Mountain Daylight Time) for a time in winter, do you want to throw an error? If they conversely specify MST (Mountain Standard Time) for a time in summer, do you want to interpret it as Mountain Daylight Time (as would be implied in most places) or Mountain Standard Time (as used in parts of Arizona) or strictly UTC-07:00 (which wasn’t even used in Arizona before year 1883)? – Ole V.V. Apr 11 '20 at 14:27

1 Answers1

1

The only "short IDs" that are supported are the ones listed in the Java docs:

EST - -05:00
HST - -10:00
MST - -07:00
ACT - Australia/Darwin
AET - Australia/Sydney
AGT - America/Argentina/Buenos_Aires
ART - Africa/Cairo
AST - America/Anchorage
BET - America/Sao_Paulo
BST - Asia/Dhaka
CAT - Africa/Harare
CNT - America/St_Johns
CST - America/Chicago
CTT - Asia/Shanghai
EAT - Africa/Addis_Ababa
ECT - Europe/Paris
IET - America/Indiana/Indianapolis
IST - Asia/Kolkata
JST - Asia/Tokyo
MIT - Pacific/Apia
NET - Asia/Yerevan
NST - Pacific/Auckland
PLT - Asia/Karachi
PNT - America/Phoenix
PRT - America/Puerto_Rico
PST - America/Los_Angeles
SST - Pacific/Guadalcanal
VST - Asia/Ho_Chi_Minh

"AKST" may be an English time zone abbreviation used by some, but it is not a "Short ID" supported by the Java Time API.

Keep in mind that the mere idea of a "Short ID" is for backwards compatibility with older Java applications where these were already in use. Generally speaking, it's not a great idea to use a few letters to identify a time zone. There are just too many ambiguities. For example, though "CST" stands for "Central Standard Time" and is mapped to America/Chicago on this list, it also stands for "Cuba Standard Time" (America/Havana) and "China Standard Time" (Asia/Shanghai) - neither of which are mapped here.

Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575