Чтобы получить ZoneId, он выглядит следующим образом:
ZoneId.of("America/Sao_Paulo");
или
ZoneId.of(ZoneId.SHORT_IDS.get("BET"));
Почему бы не причина отсутствия Enum таких значений, как:
ZoneId.of(ZoneIds.AMERICA_SAO_PAULO);
который кажется менее подверженным ошибкам и намного более удобным для автозаполнения?
Я верю, потому что список всех возможных имен часовых поясов может меняться независимо от версии Java.
Информация о часовом поясе поставляется с установкой Java (обычно в папке <java-home>/lib/zi или в jre/lib/tzdb.dat файле в новых версиях). Но эта информация может быть обновлена без изменения версии Java (используя Инструмент обновления часового пояса).
Если данные о часовом поясе обновляются (но версия Java остается прежней), и создается новый идентификатор зоны, для него не будет эквивалента Enum, оставив API "неполным". И данные временной зоны изменяются быстрее, чем обновления JDK - даже если это не так, не всегда возможно обновить версию JDK в производственных средах, как только мы хотели бы.
Я не могу говорить за создателей API, но я думаю, что они решили оставить его так, как это происходит, потому что пространство имен может увеличиваться быстрее, чем JDK обновляется, а поддержание обновленной информации будет бесконечным и всегда-неполная работа.
Если вы действительно хотите проверить, действительно ли имя часового пояса, вы можете сделать:
if (ZoneId.getAvailableZoneIds().contains("America/Sao_Paulo")) {
// America/Sao_Paulo is a valid ID
}
Или просто вызовите ZoneId.of("zone-name") и поймайте ZoneRulesException.
Я только что назвал ZoneId.getAvailableZoneIds() в JDK 1.8.0_131 и имеет 600 записей. Вероятно, никто не хотел создавать 600 констант enum.
Можно утверждать, что они могли бы сделать что-то похожее на класс java.util.Locale, который содержит несколько записей для некоторых языков (например, английский, немецкий, французский и т.д.). Но как решить, какие временные интервалы "заслуживают" константу? Может быть, они просто решили не слишком много думать об этом и "эй, забудь об этом, просто используйте String с названием зоны".
Другой возможной причиной может быть тот факт, что метод ZoneId.of() был разработан так, чтобы также получать смещения UTC (например, +05:00, -0300, +09:30:15 и т.д.). Поскольку смещения принимают часы, минуты и секунды, есть сотни возможных смещений, и создание перечислений для каждого из них будет непрактичным.
Опять же, можно было бы утверждать: "Эй, создайте только перечисления для имен и забудьте о смещениях". Но возможные причины не создавать имена перечислений уже обсуждались выше.
Набор временных зон в JDK может быть полностью заменен.
Таким образом, невозможно определить enum для зон.
Кроме того, идентификаторы часовых поясов относительно нестабильны. Они переименовываются, объединяются и обычно меняются. (Различные люди, включая меня, пытались получить большую стабильность в базе данных IANA, но сторонник базы данных не согласен.)
Запрос на вытягивание для создания класса ZoneIds в ThreeTen-Extra будет считаться константами.
Если вы видите описание метода ZoneId # getAvailableZoneIds, то вы знаете, почему?
Этот набор включает строчную форму всех доступных идентификаторов на основе регионов. Идентификаторы зоны на основе смещения не включены в возвращаемом наборе. Идентификатор можно передать в
of(String)для создания ZoneId.Набор идентификаторов зон может со временем увеличивать, хотя в типичном приложении набор идентификаторов фиксирован. Каждый вызов этого метода является потокобезопасным.