Есть ли у меня способ избежать повторного создания множества объектов String?

Question

Мой проект использует Javascript и Java (Android) для клиента и Java для бэкэнда.

Когда я начал работать над своим проектом, я сохранял даты как дни с эпохи (долго) и все было хорошо. Затем я обнаружил, что мой проект плохо работает с часовыми поясами. Внезапно свидания превратились в +1 -1 выходной. В зависимости от местоположения клиента в мире.

После небольшого исследования я увидел, что надежный способ избежать этого - сохранить даты в виде String yyyy-MM-ddT00: 00, поэтому при использовании Javascript новый Date (dateStr), он создает его правильно, и все было хорошо. Конечно, я мог бы сохранить даты как yyyy-MM-dd и просто отправить его клиенту как yyyy-MM-ddT00: 00, но это не решит мой вопрос.

После этого мне стало интересно правильно ли обрабатывается Java (backend). Я использую LocalDate, когда хочу «поиграть» с датами, а LocalDate.parse не любит формат yyyy-MM-ddT00: 00, вместо этого он работает с yyyy-MM-dd, поэтому всякий раз, когда мне нужны даты, я использовал LocalDate.parse(dateStr.substring(0,10)). LocalDateTime действительно работает с yyyy-MM-ddT00: 00, но мне не нужна временная часть, и у нее были свои проблемы, которые я не помню, какими они были в данный момент.

Итак, теперь у меня есть множество манипуляций со строками (внутри циклов), которые фактически создают больше объектов String. Можно сказать, что это не так уж и много стресса, и мне не следует обращать на это внимание, но я хочу убедиться, что я чего-то не упускаю, и, возможно, есть другой способ (возможно, достаточно глупый, который я пропустил), чтобы преодолеть это.

Спасибо

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

Я использую new Date(dateStr) в Javascript. Если dateStr - 2020-06-17, объект даты использует часовой пояс клиента, а дата может быть + -1 в зависимости от часового пояса клиента. Если dateStr равно 2020-06-17T00: 00, то объект даты создается, как ожидалось, независимо от того, где находится клиент.

Предполагая вышеизложенное, что, я надеюсь, теперь яснее, создавая объекты String снова и снова это стресс памяти, который я должен учитывать, или это что-то, с чем Java справляется без проблем, и я не должен беспокоиться об этом?

Мой вопрос был закрыт, и мне сказали отредактировать его, чтобы он был более целенаправленным. После редактирования моего вопроса, как я могу снова открыть свой вопрос для ответов?

Answer 1

Как вы обнаружили, сохранение дат в днях, начиная с некоторой эпохи, работает только в том случае, если все, кто использует вашу систему, используют один и тот же часовой пояс. Если два разных пользователя в разных часовых поясах имеют разное представление о дате, когда произошло какое-то событие (например, человек из Нью-Йорка говорит, что система вышла из строя в воскресенье вечером, но человек в Гонконге говорит, что произошел сбой в понедельник утром ), то вы должны сохранить часовой пояс, в котором произошло событие, чтобы точно показать дату этого события.

Но если вы находитесь в такой ситуации, почему бы просто не сохранить часовой пояс вместе с датой? Нет веских причин для объединения даты и часового пояса в строку.

Когда вы анализируете временную метку в формате ISO в LocalDate, используя только первые 10 символов, помните, что вы теряете часовой пояс Информация. Неявно LocalDate, который вы получаете, находится в часовом поясе исходной отметки времени. Итак, если исходная метка времени - это время Нью-Йорка, и вы берете часть даты и добавляете 1 день, тогда вы получите следующий день в часовом поясе Нью-Йорка. Но если вы затем возьмете дату из второй метки времени, вы не сможете сравнить ее с датой, полученной из первой метки времени, с точки зрения определения того, представляет ли она «тот же день». Вы можете проверить «тот же день», только если обе даты неявно находятся в одном часовом поясе.

ОБНОВЛЕНИЕ

Прочитав ваши дополнительные комментарии, я понял, что происходит вот что. У вас есть дата, хранящаяся в вашей базе данных, например, 2020-06-15. Вы отправляете это в пользовательский интерфейс в виде строки '2020-06-15', а затем делаете new Date('2020-06-15'), а затем вы удивляетесь, когда вы визуализируете дату в пользовательском интерфейсе и получаете 14 июня!

Это происходит преобразование:

• Строка '2016-06-15' разбирается на JavaScript Date, представляющую полночь UT C 15 июня.
• При рендеринге дата, она преобразуется в строку с использованием местного часового пояса браузера, который (если вы находитесь в США) даст вам 14 июня, потому что в полночь UT C 15 июня это все еще 14 июня. зоны к западу от Гринвича.

Вы обнаружили, что если вы создадите строку «2020-06-15T00: 00», это будет работать, потому что теперь JavaScript использует местный часовой пояс браузера для анализа строки . Другими словами, эта строка означает полночь по местному времени, а не UT C 15 июня. Итак, теперь последовательность:

• '2020-06-15T00:00' анализируется с использованием местного часового пояса и становится 15 июня. 4:00 AM UT C.
• Когда вы визуализируете дату, она конвертируется обратно в местное время и отображается как 15 июня.

Самый простой способ избежать всего этого беспорядок - это просто отправить обычную строку даты '2020-06-15' в пользовательский интерфейс и отобразить ее с использованием DateTimeFormat, указав часовой пояс как UT C:

new Intl.DateTimeFormat('en-US', {timeZone: 'UTC'}).format(d)

Поскольку даты в JavaScript всегда UT C, и вы просите DateTimeFormat вывести дату в UT C, сдвига даты не происходит.

Вы также можете использовать Date методы getUTCFullYear, getUTCMonth , и др. c. чтобы получить компоненты даты и отформатировать их по своему усмотрению.

Если вы больше не отправляете даты туда и обратно с добавлением «T00: 00», вы можете просто использовать LocalDate на стороне Java .

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