UTC и DST для прошлых и будущих событий

Question

Я работаю над системой, которая будет использоваться только в одном часовом поясе, но интегрируется с другими системами, которые предоставляют даты и время в utc, поэтому мы подумали, что мы идем utc all путь также. Мы также слышали о том, что сохранение времени в utc - это способ пойти в любом случае, поэтому он чувствовал себя как самый простой путь для минимизации проблем. В последнее время мы столкнулись с некоторыми проблемами. Мы регистрируем события в системе, которые представляют ценность для пользователя, поэтому мы позволяем пользователю искать и просматривать их. Швеция находится в часовом поясе +1, поэтому событие в 09:00 по местному времени будет храниться как 0800 у.е. Когда вы показываете события для пользователя, мы можем успешно преобразовать их обратно в локальное время, пока совсем недавно, когда наступит переход на летнее время. Перевод 0800 utc в локальное время теперь добавит 2 часа. Зарегистрированное событие теперь, похоже, произошло в 10:00. Как я должен справиться с этим? В этом случае, когда сохраненное время совпадает с временем, которое было фактически сохранено в db, я мог бы просто посмотреть дату и настроить ее в зависимости от того, включено ли dst в это конкретное время. Тем не менее, я думаю, мне нужно общее решение для этого, поскольку в системе будут созданы временные метки (в других местах), которые должны представлять будущие и прошлые моменты времени. Мне кажется, у меня есть 2 варианта. 1. Вернитесь к сохранению локальных времен и просто выполните дополнительную работу, когда я интегрируюсь с другими системами, использующими utc, или 2. вместе с каждой временной меткой utc хранят некоторые данные, которые могут сказать мне, была ли создана временная метка во время dst или нет. Я ошибаюсь? Правильно? Что-то пропало?

Answer 1

Вы всегда можете получить смещение часового пояса клиента с помощью метода getTimezoneOffset. Теперь все, что осталось, - применить это временное смещение к дате UTC, хранящейся в вашей базе данных, и отобразить правильную дату для конечного пользователя. Если, с другой стороны, вам нужно отобразить смещение часового пояса, используемое пользователем, когда событие было записано в вашей базе данных, тогда вы определенно добавили дополнительный столбец в своей БД для записи этого смещения. Все становится сложным, если вы хотите обрабатывать несколько часовых поясов: что происходит, когда вы хотите отображать запись для пользователя в Индии, который был отправлен пользователем в Швеции?

Answer 2

Главное, что вам не хватает, это то, что вы не можете просто думать о Швеции как о часовом поясе +1. Часовой пояс и смещение часового пояса - это две разные вещи. Прочтите the timezone tag wiki для получения более подробной информации.

Вместо этого, вы можете взять один из двух следующих подходов:

1. Подумайте о часовом поясе, в терминах его IANA tzdb identifier. Для Швеции используйте Europe/Stockholm. Сделайте свои конверсии между UTC и местным временем, используя этот часовой пояс, используя язык, библиотеку или платформу, которая реализует базу данных tz.

2. Вместо того, чтобы выяснить, что такое часовой пояс на стороне клиента, полагайтесь на клиентскую операционную систему, чтобы сделать переходы по местному времени. Большая часть среды (включая JavaScript в веб-браузере) может конвертировать из UTC в локальное время и наоборот. При таком подходе передавайте только время UTC между клиентом и сервером.

Кроме того, вы не спрашивали в этом вопросе, но в заголовке вы упомянули будущие события. Это совсем другой сценарий, и часто требует, чтобы фиксировал местное время и часовой пояс IANA. См. this answer for more details.

Возможно, вы также хотели бы написать Daylight saving time and time zone best practices.