Вопрос: Лучшее время для летнего времени и часовых поясов [закрыто]


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

Если у вас есть что добавить, пожалуйста, сделайте

Многие системы зависят от сохранения точного времени, проблема связана с изменениями времени из-за перехода на летнее время - перемещение часов вперед или назад.

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

  • Как вы справились с проблемой летнего времени?
  • Какие предположения являются частью вашего решения? (поиск контекста здесь)

Как важно, если не более того:

  • Что вы попробовали, это не сработало?
  • Почему это не сработало?

Я был бы заинтересован в программировании, ОС, сохранении данных и других соответствующих аспектах проблемы.

Общие ответы велики, но я также хотел бы видеть детали, особенно если они доступны только на одной платформе.


1875


источник


Ответы:



Резюме ответов и других данных: (пожалуйста, добавьте ваши)

Делать:

  • Всякий раз, когда вы ссылаетесь на точный момент времени, сохраняйте время в соответствии с единым стандартом, на который не влияет дневная экономия. (GMT и UTC эквивалентны в этом отношении, но предпочтительно использовать термин UTC. Обратите внимание, что UTC также известен как зулус или Z время.)
  • Если вместо этого вы решите сохранить время с использованием местного значения времени, включите локальное смещение по времени для данного конкретного времени с UTC (это смещение может меняться в течение года), так что метка времени может быть позже интерпретирована однозначно.
  • В некоторых случаях вам может потребоваться хранить и то и другое время UTC и эквивалентное местное время. Часто это делается с двумя отдельными полями, но некоторые платформы поддерживают datetimeoffsetтип, который может хранить оба в одном поле.
  • При сохранении временных меток в качестве числового значения используйте Время в Unix - это число целых секунд с 1970-01-01T00:00:00Z(исключая секунды прыжка). Если вам требуется более высокая точность, вместо этого используйте миллисекунды. Это значение всегда должно основываться на UTC без какой-либо регулировки часового пояса.
  • Если позже вам понадобится изменить временную метку, включите исходный идентификатор часового пояса, чтобы определить, может ли смещение быть изменено с записанного исходного значения.
  • При планировании будущих событий обычно предпочитается местное время вместо UTC, так как обычно смещение изменяется. См. Ответ , а также Сообщение блога ,
  • При сохранении целых дат, таких как дни рождения и юбилеи, не конвертируйте в UTC или в любой другой часовой пояс.
    • Когда это возможно, сохраните в типе данных только для даты, который не включает время суток.
    • Если такой тип недоступен, обязательно обязательно игнорируйте время дня при интерпретации значения. Если вы не можете быть уверены, что время суток будет проигнорировано, выберите 12:00 полдень, а не 00:00 Midnight, как более безопасное представительное время в этот день.
  • Помните, что смещения часовых поясов не всегда являются целым числом часов (например, индийское стандартное время - UTC + 05: 30, а Непал использует UTC + 05: 45).
  • Если вы используете Java, используйте java.time для Java 8 или использовать Время в Джоде для Java 7 или ниже.
  • При использовании .СЕТЬ , рассмотрите возможность использования Время Ноды ,
  • Если вы используете .NET без времени Noda, считайте, что DateTimeOffsetчасто является лучшим выбором, чем DateTime,
  • Если вы используете Perl, используйте DateTime ,
  • Если вы используете Python, используйте pytz или dateutil ,
  • Если вы используете JavaScript, используйте moment.js с момент- часовой пояс расширение.
  • Если вы используете PHP> 5.2, используйте преобразования местных часовых поясов, предоставленные DateTime, а также DateTimeZoneклассы. Будьте осторожны при использовании DateTimeZone::listAbbreviations()- см. ответ , Чтобы сохранить PHP с актуальными данными Олсона, установите периодичность timezonedb Пакет PECL; см. ответ ,
  • Если вы используете C ++, обязательно используйте библиотеку, которая правильно использует База данных часовых поясов IANA , К ним относятся cctz , ICU , а также Библиотека «tz» Говарда Хиннанта ,
    • Не используй Увеличение для конверсий часовых поясов. В то время как его API утверждает, что поддерживает стандартные идентификаторы IANA (aka «zoneinfo»), грубо отображает их к данным в стиле POSIX, не учитывая богатую историю изменений, которые могли иметь каждая зона. (Кроме того, файл вышел из обслуживания.)
  • Большинство бизнес-правил используют гражданское время, а не UTC или GMT. Поэтому планируйте преобразование временных меток UTC в локальный часовой пояс перед применением прикладной логики.
  • Помните, что временные зоны и смещения не являются фиксированными и могут меняться. Например, исторически США и Великобритания использовали те же даты, что и «весна вперед» и «отступать». Однако в 2007 году США изменили даты, когда часы меняются. Это означает, что в течение 48 недель в году разница между лондонским временем и временем в Нью-Йорке составляет 5 часов и 4 недели (3 весной, 1 осенью) - 4 часа. Помните о таких элементах при любых вычислениях, которые включают несколько зон.
  • Рассмотрим тип времени (фактическое время события, время трансляции, относительное время, историческое время, повторяющееся время), какие элементы (временная метка, смещение часового пояса и имя часового пояса) необходимо сохранить для правильного поиска - см. «Типы времени» в этот ответ ,
  • Храните файлы ОС, базы данных и приложений tzdata в синхронизации, между собой и остальным миром.
  • На серверах установите аппаратные часы и часы ОС на UTC, а не на локальный часовой пояс.
  • Независимо от предыдущей отметки, серверный код, включая веб-сайты, должен никогда ожидайте, что локальный часовой пояс сервера будет чем-то конкретным. см. ответ ,
  • Предпочитаете работать с часовыми поясами в каждом конкретном случае в коде приложения, а не глобально через настройки файла конфигурации или значения по умолчанию.
  • использование NTP услуг на всех серверах.
  • При использовании FAT32 , помните, что временные метки сохраняются в локальное время, а не в формате UTC.
  • Если вы имеете дело с повторяющимися событиями (например, еженедельным телешоу), помните, что время изменяется с помощью DST и будет отличаться по часовым поясам.
  • Всегда запрашивайте значения даты и времени как нижняя граница включительно, эксклюзивный эксклюзивный ( >=, <).

Не рекомендуется:

  • Не путайте «часовой пояс», например America/New_Yorkс «смещением часового пояса», например -05:00, Это две разные вещи. Видеть wiki темы часового пояса ,
  • Не используйте JavaScript Dateобъект для выполнения вычислений даты и времени в старых веб-браузерах, так как ECMAScript 5.1 и ниже дефект дизайна который может неправильно использовать летнее время. (Это было исправлено в ECMAScript 6/2015).
  • Никогда не доверяйте часам клиента. Возможно, это неверно.
  • Не говорите людям «всегда использовать UTC везде». Этот широко распространенный совет близок к нескольким допустимым сценариям, описанным ранее в этом документе. Вместо этого используйте соответствующую ссылку времени для данных, с которыми работаете. ( проставление даты может использовать UTC, но планирование в будущем времени и значения даты не должны.)

Тестирование:

  • При тестировании убедитесь, что вы тестируете страны в западных, восточных, северных и южный полушариях (фактически в каждой четверти земного шара, так что в 4 регионах), причем оба ДСТ находятся в процессе, а не (дают 8), и страна, которая не использует DST (еще 4 для охвата всех регионов, что составляет 12 в общей сложности).
  • Тестовый переход DST, т. Е. Когда вы находитесь в летнее время, выберите значение времени зимой.
  • Проверьте граничные случаи, такие как часовой пояс, который является UTC + 12, с DST, делая местное время UTC + 13 летом и даже в местах, где зимой + 13
  • Проверьте все сторонние библиотеки и приложения и убедитесь, что они правильно обрабатывают данные часового пояса.
  • Проверяйте полчаса часовых поясов, по крайней мере.

Справка:

Другие:

  • Лобби вашего представителя, чтобы прекратить мерзость, которая является DST. Мы всегда можем надеяться ...
  • Лобби для Стандартное время Земли

792



Я не уверен, что я могу добавить к ответам выше, но вот несколько моментов от меня:

Типы времени

Есть четыре разных раза, которые вы должны учитывать:

  1. Время события: например, время, когда происходит международное спортивное событие, или коронация / смерть / и т. Д. Это зависит от часового пояса события, а не от зрителя.
  2. Телевизионное время: например, конкретное телешоу транслируется в 9 вечера по местному времени по всему миру. Важно, когда вы думаете о публикации результатов (например, American Idol) на своем веб-сайте
  3. Относительное время: например: у этого вопроса открыта открытая щедрость за 21 час. Это легко отобразить
  4. Повторяющееся время: например: ТВ-шоу проводится каждый понедельник в 9 вечера, даже когда меняется летнее время.

Существует также историческое / альтернативное время. Это раздражает, потому что они не могут вернуться к стандартному времени. Например: юлианские даты, даты в соответствии с лунным календарем на Сатурне, календарь Клингонов.

Хранение времени начала / окончания в UTC работает хорошо. Для 1 вам потребуется имя часового пояса + смещение, сохраненное вместе с событием. Для 2 вам нужен локальный идентификатор времени, хранящийся в каждом регионе, и локальное имя часового пояса + смещение, хранящееся для каждого зрителя (это можно получить из IP-адреса, если вы находитесь в хрусте). Для 3, сохранить в UTC секунд и нет необходимости в часовых поясах. 4 - частный случай 1 или 2 в зависимости от того, является ли это глобальным или локальным событием, но вам также необходимо сохранить создан в чтобы вы могли определить, изменилось ли определение часового пояса до или после создания этого события. Это необходимо, если вам нужно показать исторические данные.

Время хранения

  • Всегда сохраняйте время в UTC
  • Преобразование в локальное время на дисплее (локальный определяется пользователем, просматривающим данные)
  • При хранении часового пояса вам нужно имя, отметка времени и смещение. Это необходимо, потому что правительства иногда меняют значения своих часовых поясов (например: правительство США изменило даты DST), и ваше приложение должно обрабатывать вещи изящно ... например: точная метка времени, когда эпизоды LOST показывали как до, так и после правил DST изменилось.

Смещения и имена

Примером приведенного выше является:

Финал Кубка мира по футболу   произошло в Южной Африке (UTC + 2 - SAST)   11 июля 2010 года в 19:00 UTC.

С помощью этой информации мы можем исторически определить точное время, когда финал WCS 2010 года имел место, даже если определение южноафриканского часового пояса изменится, а также иметь возможность отображать это для зрителей в их локальном часовом поясе в момент запроса базы данных.

Системное время

Вам также необходимо синхронизировать файлы операционной системы, базы данных и приложений tzdata, как друг с другом, так и с остальным миром, и тщательно тестировать при обновлении. Не неслыханно, что стороннее приложение, от которого вы зависите, неправильно обрабатывало изменения TZ.

Убедитесь, что аппаратные часы установлены на UTC, и если вы используете серверы по всему миру, убедитесь, что их ОС настроены на использование UTC. Это становится очевидным, когда вам нужно копировать почасовые файлы файлов apache с серверов в несколько часовых поясов. Сортировка их по имени файла работает только в том случае, если все файлы названы с тем же часовым поясом. Это также означает, что вам не нужно делать математику с датой в голове, когда вы ssh из одной коробки в другую, и вам нужно сравнить временные метки.

Кроме того, запустите ntpd на всех ящиках.

клиенты

Никогда не доверяйте метке времени, которую вы получаете с клиентской машины, как действительный. Например, заголовки Date: HTTP или javascript Date.getTime()вызов. Они хороши при использовании в качестве непрозрачных идентификаторов или при выполнении математики даты в течение одного сеанса на одном и том же клиенте, но не пытайтесь перекрестно ссылаться на эти значения на то, что у вас есть на сервере. Ваши клиенты не запускают NTP и могут не иметь рабочий аккумулятор для своих часов BIOS.

пустяки

Наконец, правительства иногда делают очень странные вещи:

Стандартное время в Нидерландах было   ровно 19 минут и 32,13 секунды   перед законом UTC от 1909-05-01   до 1937-06-30. Этот часовой пояс   точно не могут быть представлены   формат HH: MM.

Хорошо, я думаю, что все готово.


287



Это важный и удивительно сложный вопрос. Истина заключается в том, что не существует полностью удовлетворительного стандарта для постоянного времени. Например, стандарт SQL и формат ISO (ISO 8601) явно недостаточны.

С концептуальной точки зрения, как правило, речь идет о двух типах данных о датах времени, и их удобно отличать (эти стандарты не соблюдаются): " физическое время " а также " гражданское время ».

«Физический» момент времени является точкой непрерывной универсальной шкалы времени, с которой связана физика (конечно, игнорируя относительность). Эта концепция может быть достаточно закодирована - сохраняется в UTC, например (если вы можете игнорировать прыжки секунд).

«Гражданское» время - это спецификация даты и времени, которая следует за гражданскими нормами: точка времени здесь полностью определяется набором полей даты и времени (Y, M, D, H, MM, S, FS) плюс TZ (спецификация часового пояса) (а также «календарь», но давайте предположим, что мы ограничиваем обсуждение григорианским календарем). Часовой пояс и календарь совместно позволяют (в принципе) отображать из одного представления в другое. Но гражданские и физические моменты времени представляют собой принципиально разные типы величин, и их следует концептуально разделять и обрабатывать по-разному (аналогия: массивы байтов и символьных строк).

Проблема запутанна, потому что мы говорим об этих событиях типа взаимозаменяемо, и потому, что гражданские времена подвержены политическим изменениям. Проблема (и необходимость различать эти понятия) становится более очевидной для событий в будущем. Пример (взято из моего обсуждения Вот ,

Джон записывает в своем календаре напоминание о каком-то событии в день 2019-Jul-27, 10:30:00, TZ = Chile/Santiago, (что компенсировало GMT-4, следовательно, соответствует UTC 2019-Jul-27 14:30:00). Но однажды в будущем страна решит изменить смещение ТЗ на GMT-5.

Теперь, когда наступит день ... должно ли это напоминание

A) 2019-Jul-27 10:30:00 Chile/Santiagoзнак равно UTC time 2019-Jul-27 15:30:00?

или

B) 2019-Jul-27 9:30:00 Chile/Santiagoзнак равно UTC time 2019-Jul-27 14:30:00?

Правильного ответа нет, если не знать, что Джон концептуально подразумевал когда он рассказал календарю «Пожалуйста, позвоните мне 2019-Jul-27, 10:30:00 TZ=Chile/Santiago».

Он имел в виду «гражданский дат» («когда часы в моем городе говорят 10:30 ")? В этом случае A) является правильным ответом.

Или он имел в виду «физический момент времени», точку в континууме линии времени нашей Вселенной, скажем, «когда следующее солнечное затмение происходит ". В этом случае ответ B) является правильным.

Несколько API-интерфейсов Date / Time имеют это право на различие: среди них, Jodatime , который является основой следующего (третьего!) Java DateTime API (JSR 310).


80



Сделать четкое архитектурное разделение проблем - точно знать, с каким ярусом взаимодействует с пользователями, и изменять дату-время для / из канонического представления (UTC). Не-UTC дата-время - презентация (следует местный часовой пояс пользователей), Модель UTC (остается уникальным для базовых и средних уровней).

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

Если вы можете приобретать и поддерживать местоположение пользователя, используйте место для систематического преобразования даты и времени (например, .NET-культура или SQL-таблица), но предоставляйте возможность конечным пользователям выбирать переопределения, если для ваших пользователей важна дата-время.

Если есть исторические обязательства по аудиту (например, точно сказать, когда Jo в AZ заплатил счет 2 года назад в сентябре) затем сохранить как UTC, так и местное время для записи (ваши таблицы преобразования будут меняться с течением времени).

Определите временной референтный часовой пояс для данных, которые поступают навалом - как файлы, веб-сервисы и т. д. У компании East Coast есть центр обработки данных в CA - вам нужно спросить и узнать, что они используют в качестве стандарта, вместо того, чтобы принимать тот или иной.

Не доверяйте смещениям временного диапазона, встроенным в текстовое представление даты и времени не соглашайтесь анализировать и следовать им. Вместо этого всегда запрашивайте, чтобы часовой пояс и / или контрольная зона были явно определены , Вы можете легко получить время со смещением PST, но время на самом деле является EST, поскольку это контрольное время клиента, и записи были просто экспортированы на сервере, который находится в PST.


52



Вы должны знать о Олсоне база данных tz , который доступен из ftp://elsie.nci.nih.gov/pub http://iana.org/time-zones/ , Он обновляется несколько раз в год, чтобы иметь дело с часто последними изменениями в том, когда (и будет ли) переключаться между зимним и летним (стандартным и летним) временем в разных странах мира. В 2009 году последний выпуск был выпущен в 2009 году; в 2010 году это было 2010n; в 2011 году это было 2011n; в конце мая 2012 года релиз был 2012c. Обратите внимание, что существует набор кода для управления данными и фактическими данными самого часового пояса в двух отдельных архивах (tzcode20xxy.tar.gz и tzdata20xxy.tar.gz). Оба кода и данные находятся в общественном достоянии.

Это источник имен часовых поясов, таких как America / Los_Angeles (и синонимы, такие как US / Pacific).

Если вам нужно отслеживать разные зоны, вам нужна база данных Olson. Как сообщалось другим, вы также хотите сохранить данные в фиксированном формате - обычно используется UTC, а также запись временного пояса, в котором были сгенерированы данные. Вы можете различать смещение от UTC в момент времени и имя часового пояса; это может изменить ситуацию позже. Кроме того, зная, что в настоящее время 2010-03-28T23: 47: 00-07: 00 (US / Pacific) может или не поможет вам интерпретировать значение 2010-11-15T12: 30 - которое предположительно указано в PST ( Тихоокеанское стандартное время), а не PDT (тихоокеанское летнее время).

Стандартные библиотеки C-библиотек не очень полезны для такого рода вещей.


Данные Олсона переместились, частично из-за того, что A D Olson скоро выйдет на пенсию, а отчасти из-за того, что был подан иск (в настоящее время уволен) против сопровождающих за нарушение авторских прав. База данных часовых поясов теперь управляется под эгидой IANA , авторитет интернет-назначенных номеров, и на первой странице есть ссылка на База данных часовых поясов , Список рассылки для обсуждения теперь tz@iana.org; список объявлений tz-announce@iana.org,


38



В целом, включают местное смещение по времени (включая смещение DST) в сохраненных временных меток: только UTC недостаточно, если позже вы захотите отобразить временную метку в своем исходном часовом поясе (и настройке DST).

Имейте в виду, что смещение не всегда является целым числом часов (например, индийское стандартное время - UTC + 05: 30).

Например, подходящими форматами являются кортеж (время unix, смещение в минутах) или ISO 8601 ,


24



Crossing the boundary of "computer time" and "people time" is a nightmare. The main one being that there is no sort of standard for the rules governing timezones and daylight saving times. Countries are free to change their timezone and DST rules at any time, and they do.

Some countries e.g. Israel, Brazil, decide each year when to have their daylight saving times, so it is impossible to know in advance when (if) DST will be in effect. Others have fixed(ish) rules as to when DST is in effect. Other countries do not use DST as all.

Timezones do not have to be full hour differences from GMT. Nepal is +5.45. There are even timezones that are +13. That means that:

SUN 23:00 in Howland Island (-12)
MON 11:00 GMT 
TUE 00:00 in Tonga (+13)

are all the same time, yet 3 different days!

There is also no clear standard on the abbreviations for timezones, and how they change when in DST so you end up with things like this:

AST Arab Standard Time     UTC+03
AST Arabian Standard Time  UTC+04
AST Arabic Standard Time   UTC+03

The best advice is to stay away from local times as much as possible and stick to UTC where you can. Only convert to local times at the last possible moment.

When testing make sure you test countries in the Western and Eastern hemispheres, with both DST in progress and not and a country that does not use DST (6 in total).


22



For PHP:

The DateTimeZone class in PHP > 5.2 is already based on the Olson DB which others mention, so if you are doing timezone conversions in PHP and not in the DB, you are exempt of working with (the hard-to-understand) Olson files.

However, PHP is not updated as frequently as the Olson DB, so just using PHPs time zone conversions may leave you with outdated DST information, and influence the correctness of your data. While this is not expected to happen frequently, it may happen, and will happen if you have large base of users worldwide.

To cope with the above issue, use the timezonedb pecl package, that's function is to update PHP's timezone data. Install this package as frequently as it is updated. (I'm not sure if this packages updates follow Olson updates exactly, but it seems to be updated in a frequency which is at least very close to Olson updates.)


18