Хотите хранить время в моей базе данных, а на уровне пользовательского интерфейса - временную метку, специфичную для часового пояса [дубликата]

Question

Хотите хранить время в моей базе данных, а на уровне пользовательского интерфейса - временную метку, специфичную для часового пояса [дубликата]

1

Для столбцов, основанных на событиях, в моей базе данных, например createdDate, я хочу сохранить значение UTC.

Я ищу совет, если то, что я сейчас делаю, правильно решает мою проблему.

В postgresql я буду использовать временную метку без столбца временной зоны
В моем scala (аналогичном java) коде, я создам timestamp как:
```
val currentMs: Long = System.currentTimeMillis
new java.sql.Timestamp(currentMs)
```
Я сохраню это значение в базе данных. Все время моего сервера будет синхронизировано. Теперь на уровне базы данных я сохраняю чистое значение UTC.
Когда я получаю данные из базы данных, я буду использовать Joda-Time, который примет значение timestamp из базы данных, а затем преобразует значение в определенный часовой пояс.

Это правильный способ делать UTC? Я что-то пропустил, потому что эта тема сбивает с толку, когда вы об этом говорите :)

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

Обновить

На шаге №2 вместо сохранения значения из java.sql.Timestamp, что, если я просто сохранил значение raw currentMs в длинном столбце. Затем в пользовательском интерфейсе я бы преобразовал время unix в определенный часовой пояс на основе зарегистрированного пользователя.

Это подходит?

Blankman 22 май 2014, в 17:53

Источник

2

Я ничего не знаю о Скале или об этом Йодатиме, о котором вы упоминаете. Однако для PostgreSQL используйте «метку времени с часовым поясом» и укажите часовой пояс при сохранении метки времени. Это будет хранить абсолютную метку времени. Затем при получении просто укажите часовой пояс вашего клиента (или используйте AT TIME ZONE t ). Понятия не имею, как все это будет работать с вашими слоями каркаса.
Richard Huxton 22 май 2014, в 15:26
0

@RichardHuxton, почему я должен указывать часовой пояс в postgresql, разве мне просто не нужно сырое время utc / unix? Я этого не понимаю
Blankman 22 май 2014, в 18:54
0

timestamp without time zone не то же самое , как время UTC. Это значение, которое интерпретируется как «местное время». Значение зависит от (и изменяется с) вашего текущего часового пояса. Этот связанный ответ может быть полезным: stackoverflow.com/questions/9571392/…
Erwin Brandstetter 22 май 2014, в 19:54
0

@RichardHuxton JodaTime станет очень важным - это основа новых API даты / времени, наконец-то введенных в Java, чтобы заменить архаичный ужас java.util.Date и не намного лучший класс Calendar .
Craig Ringer 23 май 2014, в 10:36
0

Я настоятельно рекомендую использовать timestamp with time zone в БД, особенно если вы храните моменты UTC. В противном случае это звучит нормально.
Craig Ringer 23 май 2014, в 10:39

Показать ещё 3 комментария

Теги:

java

postgresql

scala

utc

jodatime

3 ответа

Ещё вопросы

Я ничего не знаю о Скале или об этом Йодатиме, о котором вы упоминаете. Однако для PostgreSQL используйте «метку времени с часовым поясом» и укажите часовой пояс при сохранении метки времени. Это будет хранить абсолютную метку времени. Затем при получении просто укажите часовой пояс вашего клиента (или используйте AT TIME ZONE t ). Понятия не имею, как все это будет работать с вашими слоями каркаса.
@RichardHuxton, почему я должен указывать часовой пояс в postgresql, разве мне просто не нужно сырое время utc / unix? Я этого не понимаю
timestamp without time zone не то же самое , как время UTC. Это значение, которое интерпретируется как «местное время». Значение зависит от (и изменяется с) вашего текущего часового пояса. Этот связанный ответ может быть полезным: stackoverflow.com/questions/9571392/…
@RichardHuxton JodaTime станет очень важным - это основа новых API даты / времени, наконец-то введенных в Java, чтобы заменить архаичный ужас java.util.Date и не намного лучший класс Calendar .
Я настоятельно рекомендую использовать timestamp with time zone в БД, особенно если вы храните моменты UTC. В противном случае это звучит нормально.

Basil Bourque · Answer 1 · 2014-05-24T19-49-00.000Z

(a) Поиск StackOverflow, так как это задано и ответили много раз.

(b) Что касается вашего элемента №1: НЕТ, не используйте TIMESTAMP WITHOUT TIME ZONE. Этот тип данных означает, что Postgres игнорирует любой указанный часовой пояс.

Эксперт Postgres Дэвид Э Уилер советует всегда использовать TIMESTAMP WITH TIME ZONE (за одним редким исключением).

Прочтите документ внимательно; не предполагайте, как работают типы данных. Названия "с/без часового пояса" являются неверными, поскольку временные метки Postgres никогда не имеют информации о часовом поясе (они оформлены в терминах UTC). Разница между "с/без часового пояса" заключается в том, соблюдаются ли временные зоны/применяются, когда данные вставлены/выбраны.

Поэкспериментируйте немного, чтобы прояснить ваше понимание.

(c) Да, обычно рекомендуется хранить ваши значения даты и времени в UTC при переходе на местное время (часовой пояс) только для презентации.

(d) Postgres имеет функции для фиксации текущего времени. Вы можете вызывать эти функции, а не делать это в коде Java/Scala, где это необходимо.

(e) Не уверен, что вы имели в виду под вторым предложением пункта 3. Если вы имеете в виду часы на компьютерах, почти всегда лучше установить часовой пояс серверов для UTC (или Рейкьявика Исландии). Но ваша база данных и программирование никогда не должны зависеть от этого.

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

Что меня смущает, так это то, почему я не могу просто сохранить unix time / utc в базе данных в длинном поле, а затем, когда я представляю время в своем пользовательском интерфейсе, просто преобразовать его на основе текущего часового пояса зарегистрированных пользователей?
@Blankman По той же причине вы не обрабатываете свой текст как массив октетов, а выполняете переводы Latin-1, UTF-8 и UTF-16 самостоятельно. Вы можете , но я уверен, что нет. Вы используете текстовые типы данных в своем языке / библиотеках программирования, полях базы данных и драйверах базы данных, чтобы помочь вам с рутинной работой по обработке текста. Так же и с датой и временем. Обработка даты и времени напрямую в виде длинных целых чисел затрудняет проверку значений, что приводит к ошибкам и путанице.
Немедленная первая проблема с датой-временем сворачивания по собственному усмотрению в виде длинных: старые классы java.util.Date и Joda-Time отслеживают время в миллисекундах с начала эпохи Unix. Новый пакет java.time в Java 8 отслеживает наносекунды начиная с эпохи Unix. Старые утилиты даты и времени отслеживают целые секунды с начала эпохи. И если вы столкнетесь с какими-либо значениями Postgres TIMESTAMP, это будут доли секунды из другой эпохи, 2000-01-01. Знаете ли вы, что существует множество эпох, используемых различными системами и библиотеками? Дата-время - грязная работа; получить всю возможную помощь
Интересно, я ценю, что вы пролили немного света на это. У меня уже болит голова :)

GreyBeardedGeek · Answer 2 · 2014-05-24T12-43-00.000Z

Возможный дубликат Что является наиболее рекомендуемым способом хранения времени в PostgreSQL с помощью Java?

Обратите внимание: postgresql фактически не сохраняет часовой пояс, независимо от имени типа данных.

Также см. Мой блог на http://greybeardedgeek.net/2012/11/24/java-dates/

Sandman · Answer 3 · 2014-05-24T09-54-00.000Z

Да, сохранение миллисов с эпохи в БД и только преобразование их в часовые пояса на местном уровне - хороший подход. Это также позволяет забыть о типах хранения данных о датах и времени и просто хранить миллины в виде числа. Это мой предпочтительный подход, а также крутая вещь: он работает с несколькими типами БД.