Обработайте разницу часовых поясов с помощью Java и Angular

Question

Разработка находится в одном месте, а развертывание - в другом месте для веб-приложения. Во время разработки я использовал свой часовой пояс для получения и сохранения значений даты в БД (Oracle).

Но после развертывания часовой пояс в другом месте совершенно другой, и дата, по-видимому, вызывает серьезную проблему в ходе тестирования.

Это простое приложение, в котором я использую Java для Backend и Angular 5 для front-end. Сохранение данных осуществляется с помощью Oracle DB.

Я не уверен, как справиться с этой разницей часовых поясов. Есть ли конкретный способ справиться с этой разницей? Любые входные данные приветствуются.

[EDIT]: Итак, требование простое - когда пользователь входит в приложение, он должен иметь возможность просматривать дату и время в соответствии со своим часовым поясом. Даже если пользователь создает / изменяет элемент, он должен иметь возможность просматривать время в соответствии со своим часовым поясом.

Например: Если я публикую сообщение / статус, тогда время в моем конце должно показывать часовой пояс для моего местоположения. Точно так же, если я вижу тот же пост / статус в другой географии, то я должен видеть время, соответствующее этому часовому поясу.

Answer 1

Все с часовыми поясами совсем не весело. Я бы хотел убедиться, что вы конвертируете свои даты в UTC на сервере и сохраняете их таким образом, а затем конвертируете их обратно на клиенте.

Я не знаю, как вы передаете даты на сервер, но что-то вроде

Определить часовой пояс из строки JSON? может быть полезным.

Для лучшего обсуждения см .:

Должен ли сервер или клиент обрабатывать часовой пояс при отправке / получении дат?

Как правильно работать с часовым поясом?

Удачи!

Edit:

Как отметил Джон Скит ниже, это не обязательно хорошая идея. Преобразование в UTC без часового пояса - это «с потерями». Если часовые пояса меняются (и они изменяются время от времени), тогда ваша временная метка UTC больше не соответствует первоначальной.

Взгляните на эту страницу и примите некоторые решения относительно ваших типов данных (TIMESTAMP WITH TIME ZONE сохранит часовой пояс, введенный пользователем, если это потребуется).

https://docs.oracle.com/cd/B19306_01/server.102/b14225/ch4datetime.htm

Практически все, что вы делаете с датами / временем, будет полно предостережений, и этот вопрос не дает много информации о требованиях приложения для хранения / отображения информации о дате и времени.

Answer 2

Я предполагаю, что вы используете объекты Java Date правильно?Если вы используете Java 8, вы должны учитывать следующие два:

OffsetDateTime
Дата-время со смещением от UTC / Гринвич в календарной системе ISO-8601, например, 2007-12-03T10: 15: 30 + 01: 00.

OffsetTime
Время со смещением от UTC / Гринвич в календарной системе ISO-8601, например 10: 15: 30 + 01: 00.

https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html

Если вы сохраняете его в Oracle и все, что вам нужно, это ДАТА, то я бы посоветовал вам сохранить его в виде строки и отформатировать, используя «ГГГГ-ММ-ДД».

По умолчанию Java JVM ВСЕГДА добавляет локальные значения JVM TZ (TimeZone) к любому объекту даты.

Итак, давайте рассмотрим бизнес-пример.Если у вас есть клиенты в 4 разных регионах США, и вам нужно сообщать о событиях даты / времени в их ЛОКАЛЬНОЕ ВРЕМЯ, то вы ДОЛЖНЫ сохранить в БД по времени GMT.По умолчанию местный TZ будет корректировать это соответственно.Встроенные в Oracle объекты Date / Time делают это по умолчанию, как и ВСЕ основные операционные системы.Поэтому создайте DIR, обратите внимание на текущее время, а затем перейдите в региональные настройки для своей ОС и измените часовой пояс.Дата создания DIR будет автоматически переведена.

В простейшем виде это идеальный случай Model-View-Controller.Где изменение TZ - Контроллер.Модель - это значение по Гринвичу, а представление переведено в часовую зону текущего пользователя.

Надеюсь, это поможет вам.ПОЖАЛУЙСТА, используйте GMT ​​и не переусердствуйте.По моему скромному мнению, сохранение в БД, не использующее GMT, вызывает проблемы.

Cheers