Отмена перехода на летнее время - правильно ли я сохраняю время? - PullRequest
Новая
       13

Отмена перехода на летнее время - правильно ли я сохраняю время?

0 голосов
/ 01 апреля 2019

В настоящее время я работаю над веб-приложением PHP / mySQL, где мы храним даты в виде меток времени Unix в столбцах UNSIGNED INT (10).Всякий раз, когда нам нужно отобразить даты в веб-представлении, мы берем это число и анализируем его с помощью moment.js.

В то время как один из моих коллег сомневался в этом способе решения задачи (он предпочитал сохранять даты как «ГГГГ»-MM-DD чч: мм: сс "VARCHARs", до сих пор у нас не было проблем.

Я недавно читал, что Европейский союз продвигается вперед в вопросе отмены перехода на летнее время.Повлияет ли это каким-либо образом на мое веб-приложение в зависимости от того, каким образом я храню даты?

Ответы [ 2 ]

0 голосов
/ 04 апреля 2019

Несколько вещей:

  • MySQL имеет стандартные типы данных, встроенные для даты и времени. Это DATE, DATETIME и TIMESTAMP. Вы можете прочитать о них больше в документации по MySQL здесь . Вы должны выбрать один из этих типов вместо хранения целых чисел или varchars.

  • То, как это относится к летнему времени, очень зависит от контекста. Не существует единого правильного способа хранить все даты и время. Любой совет «всегда хранить в UTC» недолговечен и не рекомендуется. Вместо этого подумайте о том, что представляют собой дата и время. Для уточнения:

    • Метка времени Unix всегда основана на UTC и, таким образом, не имеет никакого отношения к летнему времени или другим эффектам часовых поясов. Это хороший способ представить метку времени, когда что-то происходит в настоящем или произошло в прошлом. В MySQL тип TIMESTAMP прекрасно согласуется с этой концепцией.

    • Если вы сохраняете запланированное время события в будущем, тогда локальная дата и время намного более важны в контексте. В MySQL вы должны хранить это в DATETIME типе. Если вы работаете с несколькими часовыми поясами, вам также потребуется идентификатор часового пояса этого события (например, America/New_York), который вы можете сохранить в VARCHAR. В этом случае летнее время очень зависит от базовых правил, связанных с этим часовым поясом. MySQL имеет такие функции, как CONVERT_TZ, которые понимают эти идентификаторы и используют либо данные о часовом поясе ОС, либо собственные таблицы часовых поясов, чтобы понять, действует ли DST.

    • Если вы работаете с целыми датами, такими как даты рождения, даты годовщины, даты найма или сводные данные к определенному рабочему дню, то вам необходимо сохранить их как дату без времени или часового пояса. Это так же, как если бы вы смотрели на квадрат даты на бумажном календаре. MySQL имеет тип DATE для этого. В этом случае летнее время не имеет значения, кроме определения того, к какой дате относится момент времени. Например, когда мы спрашиваем, какой день является «сегодня», мы также рассматриваем время и часовой пояс, включая летнее время, но как только мы сообщаем «4 апреля 2019 года», тогда вся эта информация удаляется.

  • Последняя часть вашего вопроса связана с тем, как реализованы базовые данные о часовых поясах и как они будут обновляться в случае отмены ТЛЧ в ЕС. Для этого я отсылаю вас к этому ответу , в котором объясняется база данных часовых поясов IANA и непосредственно рассматривается текущая проблема ЕС.

0 голосов
/ 01 апреля 2019

Я выйду и скажу нет, это не должно иметь значения.Я не эксперт, но я также храню даты как временные метки UNIX, и если вы генерируете свои 10-значные временные метки, что-то вроде: 

getSecondsSinceEpoch = ((date) => Math.floor(date.getTime()/1000));

(или что-либо, опирающееся на Date.prototype.getTime () ), тогда вы сохраняете универсальную дату, которая не заботится о часовых поясах, что хорошо, потому что если пользователь входит в систему из другого часового пояса, вы не возвращаете varchars, основанные на том, гдеони были.То же самое относится к случаю, когда летнее время меняет часы в своем часовом поясе (или не может сделать это после отмены.)

Чтобы получить правильную читабельную строку для текущего местоположения пользователя, Javascript использует timezoneOffset , который не является частью объекта даты, но вместо этого отвечает на вопрос "на сколько часовых поясов от Лондона сейчас находится этот браузер?"(за исключением минут, а не часов и после учета перехода на летнее время.) Предположительно, устройство пользователя узнает об изменении, как и его браузер, и ваш сценарий сможет действовать соответствующим образом.(Если их устройство использует неправильный часовой пояс, ваше приложение будет не единственным, которое плохо себя ведет, пока они не разберутся с ним.)

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

...