Почему Java считывает свои настройки по умолчанию из системы

Java читает локаль, часовой пояс и информацию о кодировании (и, возможно, больше) из системы, на которой она установлена.

Это часто приносит плохие сюрпризы (принесло мне только вчера). Предположите, что ваши серверы разработки и производства настроены на TimeZone GMT + 2. Затем вы развертываете на рабочем сервере, установленном на GMT. 2-часовой сдвиг может быть нелегко наблюдать немедленно. И хотя вы можете передать TimeZone в свои календари, API-интерфейсы могут создавать календарные календари (или даты), используя часовой пояс по умолчанию.

Теперь я знаю, что нужно быть осторожным с этими настройками, но легко пропустить, следовательно, сделать программы более подверженными ошибкам.

Итак, почему у Java нет собственных значений по умолчанию - UTF-8, GMT, en_US (да, я нахожусь в не-en_US locale, но по умолчанию это нормально). При необходимости приложения могут считывать системные настройки с помощью какого-либо API.

Таким образом, программы будут более предсказуемыми.

Итак, в чем причина этого решения?

Ответ 1

Это не уникально для Java. Во многих системах по умолчанию используется системный часовой пояс. В конце концов, что еще они могут сделать?

Часовые пояса - это сложные проблемы, особенно когда приложение должно иметь дело с несколькими часовыми поясами. Вот почему сайты, такие как этот, помещают все в UTC.

Что касается вашей ситуации, трудно комментировать, потому что описание довольно расплывчато, но похоже, что это ваша ошибка. Если вы сохраняете дату (без часового пояса) в одном месте в GMT + 2, а затем загружаете ее в GMT, то вы сделали что-то неправильно.

Ответ 2

Я не понимаю, почему использование дополнительного набора параметров по умолчанию сделает это проще. Разумеется, эти значения по умолчанию все равно должны быть прочитаны откуда-то, поэтому они предположительно по умолчанию из операционной системы.

Если вы хотите повлиять на настройки по умолчанию, обычно вы можете установить системные свойства при запуске приложения, например.

java -Duser.timezone=Europe/London

и др.

Лично я думаю, что проблема заключается не в выборе дефолта, а в том, что он так легко использовал. Даже Joda Time (что очень нравится во многих отношениях) делает слишком легким случайное использование часового пояса по умолчанию. То же самое происходит с кодировками и т.д.

EDIT: Другой вариант - использовать метод main (или другой модуль ранней инициализации), который вызывает

TimeZone.setDefault(TimeZone.getTimeZone("Etc/UTC"));

а также для других системных значений по умолчанию.

Ответ 3

Я считаю, что это менее удивительно для большего количества людей.

В большинстве программ (в том числе на других языках) используется часовой пояс локального развертывания. Это было вечно. Если вы хотите что-то еще, вы можете переопределить его. Представьте, если бы это было наоборот: у нас был бы тот же вопрос в обратном направлении, но он спросил больше людей.

(Используйте UTC для временных меток, где вы не можете просто иметь смещение от эпохи.)

Ответ 4

Я могу представить себе эту потребность, когда вы разрабатываете корпоративное (сетевое) приложение, работающее на сервере, к которому должны обращаться все в мире, но это не требуется для обычных настольных приложений. Постарайтесь думать и в их контексте. Вы не хотите, чтобы пользователи-программисты, не знающие клиента, настраивали свои системные настройки по умолчанию только потому, что у Java свои собственные значения по умолчанию. Вы, как разработчик приложений (веб-приложений), действительно должны сами учитывать эти вещи.

Ответ 5

Если вы развертываете вещи на рабочем сервере, установленном в GMT, разумное поведение по умолчанию - использовать GMT по умолчанию. Предполагается, что Java является языком программирования и каркасом, а не всей операционной системой внутри системы. Поддержание собственного набора параметров по умолчанию не является частью стандартного задания библиотеки.

И рассмотрим альтернативную ситуацию: если Java действительно сохранила свои собственные настройки для таких вещей, как часовые пояса, все, кто хотел использовать разные настройки (например, все не в GMT, вероятно, ~ 90% пользователей компьютеров), которые хотели использовать Java программе придется вручную изменить часовой пояс Java. Это было бы еще сложнее для людей, которые используют системы, которые сочетают Java с другим языком, потому что у вас будут разные программы на одном компьютере с использованием разных (и, вероятно, несовместимых) настроек.