是否有java.time.ZoneId不包含ZoneIds枚举的原因? [英] Is there a reason for java.time.ZoneId not including an Enum of ZoneIds?

问题描述

要获得ZoneId，它就像:

ZoneId.of("America/Sao_Paulo");

或

ZoneId.of(ZoneId.SHORT_IDS.get("BET"));

为什么会不存在这样的值Enum的原因，例如:

Why would be the reason for not existing an Enum of such values, like:

ZoneId.of(ZoneIds.AMERICA_SAO_PAULO);

似乎不太容易出错，而对自动完成更友好?

which seems less error-prone and a lot more auto-complete friendly?

推荐答案

我相信这是因为所有可能的时区名称列表都可以更改，而与Java版本无关.

I believe it's because the list of all possible timezones names can change regardless of Java version.

时区信息随Java一起安装(通常在文件夹<java-home>/lib/zi中，或在较新版本的jre/lib/tzdb.dat文件中).但是，该信息可以在不更改Java版本的情况下进行更新(使用时区更新工具).

Timezone information comes with Java installation (usually in the folder <java-home>/lib/zi, or in jre/lib/tzdb.dat file in newer versions). But this information can be updated without changing the Java version (using the Timezone Updater Tool).

如果时区数据已更新(但Java版本保持不变)并且创建了新的时区ID，则将没有等效的Enum，从而使API处于不完整"状态.并且时区数据更改的速度比JDK更新的速度快-并非如此，并非总是可以在生产环境中尽快更新JDK版本.

If the timezone data is updated (but Java version stays the same) and a new zone ID is created, there would be no equivalent Enum for it, leaving the API "incomplete". And timezone data changes faster than JDK updates - even if it didn't, it's not always possible to update the JDK version in production environments as soon as we'd like.

我不能代表API创建者，但是我认为他们决定保留它的原样，因为名称空间可以比JDK更新更快地增长，并且保持枚举为最新状态将是无穷无尽的.和总是不完整的工作.

I can't speak for the API creators, but I think they decided to leave it the way it is because the namespace can increase faster than the JDK is updated, and maintaining the enums up-to-date would be an endless and always-incomplete job.

如果您确实要检查时区名称是否有效，则可以执行以下操作:

If you really want to check if a timezone name is valid, you can do:

if (ZoneId.getAvailableZoneIds().contains("America/Sao_Paulo")) {
    // America/Sao_Paulo is a valid ID
}

或者只是调用ZoneId.of("zone-name")并赶上ZoneRulesException.

我刚刚在 JDK 1.8.0_131 中调用了ZoneId.getAvailableZoneIds()，它有600个条目.可能没有人想要创建600个枚举常量.

I've just called ZoneId.getAvailableZoneIds() in JDK 1.8.0_131 and it has 600 entries. Probably nobody wanted to create 600 enum constants.

一个人可能会说他们可以做类似于java.util.Locale类的事情，该类为某些语言(例如英语，德语，法语等)提供了一些条目.但是，如何确定哪个时区值得"一个常数呢?也许他们只是决定不去考虑太多，而嘿，算了，只需使用区域名称为String的.

One could argue that they could've done something similar to java.util.Locale class, which has a few entries for some languages (like English, German, French, etc). But how to decide which timezones "deserve" a constant? Maybe they just decided to not think too much about that and "hey, forget it, just use a String with the zone name".

另一个可能的原因可能是ZoneId.of()方法被设计为还接收UTC偏移量的事实(例如+05:00，-0300，+09:30:15等).由于偏移量接受小时，分钟和秒，因此有数百种可能的偏移量，并且为每个偏移量创建枚举是不切实际的.

Another possible reason can be the fact that ZoneId.of() method was designed to also receive UTC offsets (such as +05:00, -0300, +09:30:15 and so on). As the offsets accept hours, minutes and seconds, there are hundreds of possible offsets and creating enums for each one would be impractical.

同样，人们可能会争辩嘿，只为名称创建枚举，而忽略偏移量"..但是上面已经讨论了不创建枚举名称的可能原因.

Again, one could argue "Hey, create just the enums for the names and forget about the offsets". But the possible reasons for not creating enum names were already discussed above.

这篇关于是否有java.time.ZoneId不包含ZoneIds枚举的原因?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！