Переход на летнее время и часовые пояса

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

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

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

Для PHP:

Класс DateTimeZone в PHP> 5.2 уже основан на базе данных Olson, которую упоминают другие, поэтому, если вы выполняете преобразование часовых поясов в PHP, а не в DB, ​​вы освобождаетесь от работы с (трудными для понимания) файлами Олсона.

Однако PHP обновляется не так часто, как БД Olson, поэтому простое использование преобразования часовых поясов PHP может привести к устаревшей информации о летнем времени и повлиять на правильность ваших данных. Хотя это не ожидается часто, это может случиться, и произойдет, если у вас будет много пользователей по всему миру.

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

Запрещено:

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

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

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

Ссылка:

• Подробная вики-страница тега часовой пояс в Stack Overflow
• База данных Olson, также известная как Tz_database
• Проект процедур IETF для поддержки базы данных Olson
• Источники для часовых поясов и DST
• Формат ISO (ISO 8601)
• Сопоставление между базой данных Olson и идентификаторами часовых поясов Windows, со страницы Консорциума Unicode
• Часовой пояс в Википедии
• Вопросы StackOverflow с тегами dst
• Вопросы StackOverflow tagged часовой пояс
• Работа с DST - лучшие практики Microsoft DateTime
• Протокол сетевого времени в Википедии

Другое:

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

Пересечение границы «компьютерного времени» и «человеческого времени» "это кошмар. Главная из них заключается в том, что не существует какого-либо стандарта для правил, регулирующих часовые пояса и летнее время. Страны могут изменять свой часовой пояс и правила летнего времени в любое время, и они это делают.

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

Часовые пояса не обязательно должны отличаться от GMT на целый час. Непал +5,45. Есть даже часовые пояса +13. Это означает, что:

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

все в одно и то же время, но 3 разных дня!

Также нет четкого стандарта в отношении сокращений часовых поясов и того, как они меняются при переходе на летнее время, так что в итоге получаются такие вещи:

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

Лучший совет - как можно больше избегать местного времени и придерживаться в UTC, где можно. Переводите на местное время только в самый последний момент.

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

Недавно у меня возникла проблема в веб-приложении, когда при Ajax post-back время даты, возвращаемое в мой код на стороне сервера, отличалось от времени даты, передаваемого наружу.

Скорее всего, это было связано с моим JavaScript-кодом на клиенте, который строил дату для отправки обратно клиенту в виде строки, потому что JavaScript корректировал часовой пояс и переход на летнее время, и в некоторых браузерах расчет времени перехода на летнее время отличался от других.

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

Мой вывод из этого: Не используйте JavaScript-вычисления даты и времени в веб-приложениях, если это АБСОЛЮТНО не нужно.

Хотя я не пробовал, подход к настройке часового пояса, который я считаю убедительным, будет следующим:

1. Хранить все в формате UTC.

2. Создайте таблицу TZOffsets с тремя столбцами: RegionClassId, StartDateTime и OffsetMinutes (int, в минутах).

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

Если вам нужно вычислить местное время для любого времени в формате UTC, просто сделайте следующее:

SELECT DATEADD('m', SUM(OffsetMinutes), @inputdatetime) AS LocalDateTime
FROM   TZOffsets
WHERE  StartDateTime <= @inputdatetime
       AND RegionClassId = @RegionClassId;

Возможно, вы захотите кэшировать эту таблицу в своем приложении и использовать LINQ или другие подобные средства для выполнения запросов, а не обращения к базе данных.

Эти данные можно извлечь из общедоступной базы данных tz .

Преимущества и сноски этого подхода:

1. В код не встроены правила, вы можете легко настроить смещения для новых регионов или диапазонов дат.
2. Необязательно поддерживать каждый диапазон дат или регионов, вы можете добавлять их по мере необходимости.
3. Регионы не обязательно должны напрямую соответствовать геополитическим границам, и чтобы избежать дублирования строк (например, в большинстве штатов США летнее время обрабатывается одинаково), вы можете иметь широкие записи RegionClass, которые связываются в другой таблице с другими традиционные списки штатов, стран и т. д.
4. Для таких ситуаций, как США, где дата начала и окончания перехода на летнее время изменилась за последние несколько лет, с этим довольно легко справиться.
5. Поскольку поле StartDateTime также может хранить время, стандартное время переключения 2:00 AM обрабатывается легко.
6. Не везде в мире используется 1-часовое летнее время. Это легко справляется с этими случаями.
7. Таблица данных является кроссплатформенной и может быть отдельным проектом с открытым исходным кодом, который может использоваться разработчиками, использующими практически любую платформу баз данных или язык программирования.
8. Это можно использовать для смещений, которые не имеют ничего общего с часовыми поясами. Например, 1-секундные корректировки, которые время от времени происходят для корректировки вращения Земли, исторические корректировки в григорианском календаре и внутри него и т. Д.
9. Поскольку это находится в таблице базы данных, стандартные запросы отчетов и т. Д. Могут Воспользуйтесь преимуществами данных, не вдаваясь в код бизнес-логики.
10. Он также обрабатывает смещения часовых поясов, если вы этого хотите, и даже может учитывать особые исторические случаи, когда регион назначен другому часовому поясу. Все, что вам нужно, это начальная дата, которая назначает смещение часового пояса для каждого региона с минимальной датой начала. Это потребует создания по крайней мере одного региона для каждого часового пояса, но позволит вам задать интересные вопросы, например: «Какая разница в местном времени между Юмой, Аризона, и Сиэтлом, Вашингтон, 2 февраля 1989 года в 5:00?» (Просто вычтите одну СУММ () из другой).

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

Установите для ваших серверов значение UTC и убедитесь, что все они настроены. настроен для ntp или аналога.

UTC позволяет избежать проблем с переходом на летнее время, а рассинхронизация серверов может привести к непредсказуемым результатам, на диагностику которых потребуется время.

Вам необходимо знать о базе данных Olson tz, которая доступна по адресу ftp://elsie.nci.nih.gov/pub http://iana.org/time-zones/. Она обновляется несколько раз в год, чтобы учесть часто происходящие в последнюю минуту изменения в том, когда (и нужно ли) переходить на зимнее и летнее (стандартное и летнее) время в разных странах мира. В 2009 году последний выпуск был 2009s, в 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 (США/Тихий океан), может помочь или не помочь вам в интерпретации значения 2010-11-15T12:30 - которое предположительно указано в PST (Тихоокеанское стандартное время), а не PDT (Тихоокеанское летнее время).

Стандартные интерфейсы библиотеки C не слишком полезны для таких вещей.

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

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

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

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

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

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

Джон записывает в своем календаре напоминание о каком-то событии в datetime 27 июля 2019 г., 10:30:00 , TZ = Чили / Сантьяго , (со смещением GMT-4, , следовательно, соответствует UTC 2019-июл-27 14:30:00 ). Но когда-нибудь в будущем страна решит изменить смещение TZ на GMT-5.

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

A) 2019-июл-27 10:30:00 Чили / Сантьяго = UTC-время 2019-июль -27 15:30:00 ?

или

B) 27 июля 2019 г. 9:30:00 Чили / Сантьяго = всемирное координированное время 27 июля 2019 г. 14:30:00 ?

Нет правильного ответа, если никто не знает, что Джон концептуально имел в виду , когда сказал календарю: «Пожалуйста, позвоните мне по телефону 2019-июл-27, 10 : 30: 00 TZ = Чили / Сантьяго ".

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

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

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

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

Типы времени

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

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

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

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

Хранение времени

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

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

Примером может быть:

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

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

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

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

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

Также запустите ntpd на всех компьютерах.

Клиенты

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

Мелочи

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

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

Хорошо, думаю, я закончил.

Четкое архитектурное разделение проблем - чтобы точно знать, какой уровень взаимодействует с пользователями и должен изменить дату и время для / от канонического представления (UTC). Дата-время, отличное от UTC, представляет собой представление (соответствует часовому поясу пользователя), Время UTC является моделью (остается уникальным для внутреннего и среднего уровней).

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

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

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

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

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

Будьте осторожны при работе с отметками времени, хранящимися в файловой системе FAT32 - они всегда сохраняются в координатах местного времени (включая DST - см. статью msdn ). Сгорел на этом.

Еще одна вещь: убедитесь, что на серверах установлено последнее обновление для перехода на летнее время.

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

Оказывается, в конце концов это были серверы. Им просто нужно было установить последний патч ( Windows Server 2003 ).