Каков наилучший способ хранения международных дат в базе данных? [Дубликат]

Question

Каков наилучший способ хранения международных дат в базе данных? [Дубликат]

Вы можете использовать enumerated(), чтобы получить как индекс, так и значение во время цикла:

for (index, element) in masterA.enumerated() {
    if index % 2 == 0 {
        evenA.append(element)
    } else {
        oddA.append(element)
    }
}

Это будет хранить каждый element из masterA с нечетным индексом в oddA и каждый элемент с четным индексом в evenA.

1889

database date internationalization timezone timestamp

задан 50 revs, 18 users 51% 25 July 2016 в 21:47

30 ответов

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

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

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

6

ответ дан 2 revs, 2 users 75% 17 August 2018 в 14:44
поделиться

Для PHP:

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

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

Чтобы справиться с вышеуказанной проблемой, используйте timezonedb pecl package , это функция обновления данных часового пояса PHP. Установите этот пакет так часто, как он обновляется. (Я не уверен, что обновления пакетов соответствуют настройкам Olson точно, но, похоже, они обновляются с частотой, которая, по крайней мере, очень близка к обновлениям Olson.)

18

ответ дан 2 revs, 2 users 82% 17 August 2018 в 14:44
поделиться

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

Типы времени

Существует четыре разных раза, рассмотрите:

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

Телевизионное время: например, конкретное телешоу транслируется в 9 вечера по местному времени по всему миру. Важно, когда вы думаете о публикации результатов (например, American Idol) на своем веб-сайте

Относительное время: например: этот вопрос закрыт открытой щедростью за 21 час. Это легко отобразить

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

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

Хранение старта / конца временных меток в 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.

Trivia

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

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

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

289

ответ дан 2 revs, 2 users 99% 17 August 2018 в 14:44
поделиться

1

В этом ответе есть несколько замечательных моментов, я особенно хотел указать на эту часть. «Повторяющееся время: например: ТВ-шоу происходит каждый понедельник в 9 вечера, даже когда изменения DST». Сохранение времени в UTC в БД, а затем преобразование для отображения помогает справиться со многими сложными аспектами работы с часовыми поясами. Однако обработка & quot; повторяющихся событий & quot; что перекрестные барьеры ДСТ становятся намного более жесткими. – Jared Hales 5 August 2010 в 14:53

2

+1 для мелочей. Сохранение контента интересно делает эту задачу более приятной, что может привести к повышению производительности :) – Chris 8 January 2011 в 07:54

3

В этом ответе много хорошего, но несколько вопросов. 1) Сокращения во многих часовых поясах неоднозначны. см. здесь 2) Не всегда вы хотите сохранить в UTC. В большинстве случаев - да, но контекст имеет значение. В ваших терминах телевизионное время не будет храниться в формате UTC. Кроме того, иногда его противозаконная или противная политика не хранит местное время - в этом случае удобны такие вещи, как DateTimeOffset (или эквивалент). В противном случае, хорошо писать. – Matt Johnson 11 January 2013 в 03:38

4

Голландские мелочи выглядят законно. ietf.org/rfc/rfc3339.txt раздел 5.8. На полпути выяснилось, что кто-то тянет нашу ногу. – ruffin 6 June 2014 в 15:13

5

Еще один пример для правительств сделать странные вещи: timeanddate.com/news/time/turkey-scraps-dst-2016.html – Ad Infinitum 21 April 2017 в 11:18

Для тех, кто борется с этим на .NET , посмотрите, стоит ли использовать DateTimeOffset и / или TimeZoneInfo.

Если вы хотите использовать Временные зоны IANA / Olson или найти встроенные типы недостаточны для ваших нужд, проверьте Noda Time , который предлагает гораздо более умный API для даты и времени для .NET.

3

ответ дан 3 revs, 2 users 60% 17 August 2018 в 14:44
поделиться

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

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

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

24

ответ дан 3 revs, 2 users 94% 17 August 2018 в 14:44
поделиться

1

Для отображения смещение идеально. Если вы хотите внести изменения, смещения все еще недостаточно. Вы также должны знать часовой пояс, потому что для нового значения может потребоваться другое смещение. – Matt Johnson 11 January 2013 в 03:30

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

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

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

Мое изучение этого: не используйте расчеты даты и времени JavaScript в веб-приложениях, если только вы НЕОБХОДИМО выполнить.

10

ответ дан 3 revs, 3 users 74% 17 August 2018 в 14:44
поделиться

1

Javascript запускается на клиентской машине, а не на сервере. Базовое datetime для Javascript - это дата-время клиента, а не дата и время сервера. – BalusC 29 March 2010 в 12:39

2

Привет, BalusC. Я понимаю это (из моего исходного сообщения: «javacode script на клиенте, который создал дату ...»). Моя проблема заключалась в том, что определенная клиентская машина обрабатывала DST в одну сторону, а некоторые другие по-другому. Поэтому я переместил всю серверную часть обработки, чтобы предотвратить странность браузера – Joon 31 March 2010 в 09:28

3

@ Joon - и есть ошибки в реализациях javascript, которые вы не можете обнаружить или разрешить. Так что да, никогда не используйте расчеты даты ECMAScript на клиентской стороне для вещей, которые имеют значение (хотя в противном случае вы можете сделать довольно хорошую работу). – RobG 16 October 2014 в 03:19

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

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

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

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

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

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

53

ответ дан 3 revs, 3 users 84% 17 August 2018 в 14:44
поделиться

Я ударил это по двум типам систем: «системы планирования сдвига (например, заводские рабочие)» и «системы управления газом» ...

23 и 25-часовые длинные дни - это боль, чтобы справиться с , так что 8hr сдвиги, которые занимают 7 часов или 9 часов. Проблема заключается в том, что вы обнаружите, что у каждого клиента или даже отдела клиента есть разные правила, которые они создали (часто без документирования) на то, что они делают в этих особых случаях.

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

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

12

ответ дан 3 revs, 3 users 88% 17 August 2018 в 14:44
поделиться

1

Моя подруга, медсестра, работает ночью, и они должны писать часовой пояс во время переключения DST. Например, 2AM CST против 2AM CDT – Joe Phillips 5 August 2010 в 03:48

2

Да, это обычное дело: когда вы вычисляете среднесуточный (средний), вы должны справляться с днями 23, 24 или 25 часов. Как следствие, при вычислении добавьте 1 день, это не добавит 24 часа ! Во-вторых, не пытайтесь создать свой собственный часовой пояс; используйте только API системы. И не забудьте обновить каждую развернутую систему, чтобы получить обновленную базу данных часового пояса . – Alex 9 October 2013 в 10:44

804

ответ дан 30 revs, 18 users 59% 17 August 2018 в 14:44
поделиться

Для Интернета правила не так сложны ...

На стороне сервера, используйте UTC

На стороне клиента используйте Olson Причина: смещения UTC не являются безопасными для летнего времени (например, в Нью-Йорке - EST (UTC - 5 часов) в течение года, EDT (UTC - 4 Hours) в остальной части года). Для определения часового пояса на стороне клиента у вас есть два варианта: 1) Использовать пользовательскую зону (безопаснее) Ресурсы: готовый к использованию в сети Olson tz Выпадающая страница HTML и JSON 2) Авто -detect zone Resource: jsTimezoneDetect

Остальное - это просто UTC / локальное преобразование, используя ваши библиотеки datetime на стороне сервера. Хорошо идти ...

10

ответ дан 4 revs 17 August 2018 в 14:44
поделиться

1

Это хороший совет в качестве отправной точки, но он полностью зависит от приложения. Это может быть хорошо для дружественного веб-сайта, но если в вашем приложении есть какой-либо юридический / юрисдикционный / финансовый аспект, который кто-то может подать в суд (я работал над несколькими), то это чрезмерное упрощение, потому что существуют разные виды " времени ", как указано в других разделах этой страницы. – DavidWalley 14 June 2017 в 20:13

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

Хранить все в UTC.

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

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

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

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

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

Эти данные могут быть перегорожены из база данных общего доступа tz .

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

Никакие правила не запекаются в код, вы можете настроить смещения для новых регионов или диапазонов дат.

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

Регионы не должны напрямую соответствовать геополитические границы и избежать дублирования строк (например, большинство государств в США обрабатывают DST одинаково), вы можете иметь широкие записи RegionClass, которые ссылаются в другой таблице на более традиционные списки государств, стран и т. д.

В таких ситуациях, как США, где начальная и конечная дата DST изменилась за последние несколько лет, с этим довольно легко справиться.

Поскольку поле StartDateTime также может хранить время, 2: 00 AM стандартное время переключения обрабатывается легко.

Не везде в мире используется 1-часовой DST. Это легко справляется с этими случаями.

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

Это может использоваться для смещений, которые не имеют никакого отношения к часовым поясам. Например, 1-секундные корректировки, которые время от времени корректируются для вращения Земли, исторические настройки в и в пределах григорианского календаря и т. Д.

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

Это также относится к смещениям часового пояса, если вы этого захотите, и может даже учитывать особые исторические случаи, когда регион назначен в другой часовой пояс. Все, что вам нужно, это начальная дата, которая присваивает часовой пояс для каждого региона с минимальной датой начала. Это потребует создания по крайней мере одного региона для каждого часового пояса, но позволит задать интересующие вас вопросы: «Какая разница в местном времени между Юмой, Аризоной и Сиэтлом, Вашингтон, 2 февраля 1989 года в 5:00?» (Просто вычтите один SUM () из другого).

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

15

ответ дан 4 revs, 2 users 95% 17 August 2018 в 14:44
поделиться

1

Идея вашей базы данных уже реализована в качестве базы данных Olson. В то время как переход на летнее время создает перекрытие, определяющее часовой пояс, соответствующий дневному свету, может помочь решить проблему. 2:15 EST и 2:15 EDT - это разные времена. Как отмечалось в других сообщениях, указывающих смещение, также устраняется двусмысленность. – BillThor 4 August 2010 в 00:04

2

Большая проблема с сохранением собственной базы данных заключается в ее обновлении. Олсон и Windows поддерживаются для вас. У меня было несколько случаев плохого перехода на DST, потому что таблицы устарели. Вытащить их полностью и полагаться на базу данных уровня или базы данных намного надежнее. – Matt Johnson 11 January 2013 в 03:28

3

Не создавайте свою собственную базу данных : всегда полагайтесь на API системы! – Alex 9 October 2013 в 10:54

Вам нужно знать о базе данных Olson 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. Как сообщали другие, вы также хотите сохранить данные в фиксированном формате & mdash; Обычно UTC - это выбранный вариант; наряду с записью часового пояса, в котором были созданы данные. Вы можете различать смещение от UTC в момент времени и имя часового пояса; это может изменить ситуацию позже. Кроме того, зная, что в настоящее время 2010-03-28T23: 47: 00-07: 00 (US / Pacific) может или не поможет вам интерпретировать значение 2010-11-15T12: 30 & mdash; который, по-видимому, указан в PST (Pacific Standard Time), а не в PDT (Pacific Daylight Saving Time).

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

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

38

ответ дан 5 revs, 3 users 80% 17 August 2018 в 14:44
поделиться

1

База данных Olson содержит данные history , что делает ее особенно полезной для обработки DST. Например, он знает, что значение UTC, соответствующее 31 марта 2000 г. в США, не находится в DST, но значение UTC, соответствующее 31 марта 2008 г. в США. – Josh Kelley 29 March 2010 в 15:29

2

Консорциум Unicode поддерживает сопоставление идентификаторов зоны Олсона и идентификаторов часовых поясов Windows: unicode.org/repos/cldr-tmp/trunk/diff/supplemental/… – Josh Kelley 29 March 2010 в 15:30

3

Обновленная ссылка для страницы Консорциума Юникода: unicode.org/repos/cldr-tmp/trunk/diff/supplemental/… – Span 2 June 2011 в 05:17

4

Где можно найти информацию о разборе файлов Olson? Я хочу скомпилировать его в таблицу db, но не могу понять, как читать файлы – shealtiel 7 September 2011 в 15:09

5

@gidireich: основная информация найдена с данными, и это непросто понять. Основная документация для него находится на странице zic.8 man (или zic.8.txt). Для получения этой информации вам понадобится файл tzcode2011i.tar.gz, а не файл tzdata2011i.tar.gz, а также файл tzdata2011i.tar.gz. – Jonathan Leffler 7 September 2011 в 15:46

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

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

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

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

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

Джон записывает в своем календаре напоминание о некотором событии в datetime 2019-Jul-27, 10:30:00, TZ = Chile/Santiago (которое имеет смещение GMT- 4, следовательно, это соответствует UTC 2019-Jul-27 14:30:00). Но в какой-то день в будущем страна решит изменить смещение TZ на 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).

81

ответ дан 6 revs, 5 users 92% 17 August 2018 в 14:44
поделиться

1

Еще один момент для рассмотрения, который я не видел в API, заключается в том, что даже когда заданы время и часовой пояс, существует, по меньшей мере, два правдоподобных значения, например. & Quot; 13: 00: 00EDT & Quot ;. Это может быть ссылка на то, что, как известно, произошло в 13:00 по местному времени, которое, как полагали, было восточным дневным светом или что-то, что, как известно, произошло в тот момент, когда восточное время достигло 13:00, что, как полагают, произошли в месте, где наблюдалось восточное летнее время. Если у вас много временных меток, где информация о часовом поясе может быть неправильной (например, файлы цифровой камеры) ... – supercat 29 October 2013 в 19:04

2

... зная, будут ли они отражать точное местное время или глобальное время, могут быть важны при определении того, как их исправить. – supercat 29 October 2013 в 19:04

3

Ясно, что Джон хочет, чтобы А), потому что люди идут на работу в 8:30, независимо от того, что такое DST или часовой пояс. Если они займутся DST, они приступят к работе в 8:30, когда они выйдут с DST, они отправятся на работу в 8:30. Если страна решит переехать в другой часовой пояс, они отправятся на работу в 8:30 – Gianluca Ghettini 9 March 2017 в 17:54

Просто хотел указать на две вещи, которые кажутся неточными или, по крайней мере, запутанными:

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

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

При хранении временных меток включайте локальное смещение по времени (включая смещение DST).

Временная метка всегда отображается в GMT и, следовательно, не имеет смещения.

2

ответ дан Alix Axel 17 August 2018 в 14:44
поделиться

1

Местное смещение по времени позволит вам воссоздать исходное «время на стене», события. Если вы не сохраните это дополнительное поле, эти данные будут потеряны. – nogridbag 16 April 2012 в 19:33

2

Да, за исключением UTC и GMT смещения являются обратными. Например, UTC-0700 совпадает с GMT + 0700. На самом деле, все цифровые данные должны использовать UTC в эти дни. – Matt Johnson 13 September 2012 в 20:36

3

@Matt: вы уверены, что UTC и GMT смещения являются обратными? где я могу это прочитать? – Reto Höhener 16 February 2013 в 16:22

4

На самом деле, я думаю, что раньше был неправильным. GMT и UTC не перевернуты сами. Это то, что есть реализации, которые показывают их в обратном порядке, такие как база данных IANA / Olson / TZDB. См. здесь . Другая область, которую вы видите смещения в обратном, - это функция getTimezoneOffset () javascript. – Matt Johnson 16 February 2013 в 19:49

5

@MattJohnson: Это хаки и должны быть отменены. – Alix Axel 17 February 2013 в 00:55

Голосование Тома Скотта о часовых поясах на YouTube на канале Computerphile также имеет приятное и интересное описание темы. Примеры включают:

Самоа (остров в Тихом океане) переводит свой часовой пояс вперед на 24 часа, чтобы облегчить торговлю с Австралией и Новой Зеландией

на Западном берегу, где 2 популяции людей следуют за разными часовыми поясами,

изменения 18-го века от юлианского календаря до григорианского календаря (что произошло в XX веке в России).

2

ответ дан Attila Tanyi 17 August 2018 в 14:44
поделиться

На самом деле kernel32.dll не экспортирует SystemTimeToTzSpecificLocation. Однако он экспортирует следующие два: SystemTimeToTzSpecificLocalTime и TzSpecificLocalTimeToSystemTime ...

1

ответ дан Brad 17 August 2018 в 14:44
поделиться

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

Несколько лет назад операционная система Android использовала спутники GPS для получения информации о времени UTC, но проигнорировала тот факт, что спутники GPS не используют скачки секунд. Никто не заметил, пока не возникла путаница в канун Нового года, когда пользователи телефонов Apple и пользователи телефонов Android сделали свои обратные отсчеты примерно на 15 секунд друг от друга.

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

1

ответ дан DavidWalley 17 August 2018 в 14:44
поделиться

Вот мой опыт: -

(не требует сторонней библиотеки)

На стороне сервера сохраняйте время в формате UTC, чтобы вся дата / time в базе данных находятся в одном стандарте независимо от местоположения пользователей, серверов, часовых поясов или DST.

На уровне пользовательского интерфейса или в сообщениях электронной почты, отправленных пользователю, вам нужно показать время в соответствии с пользователем. В этом случае вам необходимо иметь смещение часового пояса пользователя, чтобы вы могли добавить это смещение в значение UTC базы данных, которое приведет к локальному времени пользователя. Вы можете либо принять смещение часового пояса пользователя при их регистрации, либо автоматически обнаружить их на веб-и мобильных платформах. Для веб-сайтов функция JavaScript getTimezoneOffset () является стандартной версией версии 1.0 и совместима со всеми браузерами. (Ссылка: http://www.w3schools.com/jsref/jsref_getTimezoneOffset.asp )

2

ответ дан Doc 17 August 2018 в 14:44
поделиться

1

Это не работает, если вы рассматриваете изменения DST. getTimezoneOffset возвращает смещение для даты и времени, когда вы его вызываете. Это смещение может измениться, когда часовой пояс переходит в или из летнего времени. См. «Часовой пояс! = Смещение». в тег часовой пояс wiki . – Matt Johnson 22 May 2015 в 18:21

2

Если вы хотите сохранить сигнал тревоги, например «сделать что-то в 10:00», вы не сможете сохранить его в UTC из-за сдвигов DST. Вы должны хранить его относительно местного времени. – Alex 23 May 2017 в 12:31

Выход PHP DateTimeZone::listAbbreviations()

Этот метод PHP возвращает ассоциативный массив, содержащий некоторые «основные» часовые пояса (например, CEST), которые сами по себе содержат более конкретные «географические» (например, Европа / Амстердам).

Если вы используете эти часовые пояса и их информацию о смещении / DST, чрезвычайно важно реализовать следующее:

Кажется, что все разные конфигурации смещения / DST (включая исторические конфигурации) каждого часового пояса включены!

Например, Европа / Амстердам можно найти шесть раз на выходе этой функции. Два события (смещение 1172/4772) относятся к Амстердамскому времени, использованному до 1937 года; два (1200/4800) относятся к тому времени, которое использовалось между 1937 и 1940 годами; и два (3600/4800) относятся к времени, используемому с 1940 года.

Поэтому вы не можете полагаться на информацию о смещении / DST, возвращаемую этой функцией , как правильную / в use!

Если вы хотите узнать текущее смещение / DST определенного часового пояса, вам нужно будет сделать что-то вроде этого:

<?php $now = new DateTime(null, new DateTimeZone('Europe/Amsterdam')); echo $now->getOffset(); ?>

5

ответ дан Jonathan 17 August 2018 в 14:44
поделиться

Используете ли вы платформу .NET? Если да, позвольте мне представить вам тип DateTimeOffset , добавленный с .NET 3.5.

Эта структура содержит как DateTime, так и смещение (TimeSpan), что задает разницу между датой и временем экземпляра DateTimeOffset и скоординированным универсальным временем (UTC).

Статический метод DateTimeOffset.Now возвращает экземпляр DateTimeOffset, состоящий из текущего (локального) время и местное смещение (как определено в региональной информации операционной системы).

Статический метод DateTimeOffset.UtcNow возвращает экземпляр DateTimeOffset, состоящий из текущего времени в UTC (как если бы вы были в Гринвич).

Другими полезными типами являются классы TimeZone и TimeZoneInfo .

3

ответ дан M.A. Hanin 17 August 2018 в 14:44
поделиться

1

Это не решение проблемы. – Cara Turpin 2 January 2014 в 23:45

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

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

Код на стороне сервера, включая веб-сайты, должен никогда ожидать локальный часовой пояс сервера

На некоторых языках локальный часовой пояс может легко входить в код приложения. Например, метод DateTime.ToUniversalTime в .NET будет конвертировать из в локальный часовой пояс в UTC, а свойство DateTime.Now возвращает текущее время в локальном часовом поясе. Кроме того, конструктор Date в JavaScript использует локальный часовой пояс компьютера. Есть много других подобных примеров. Важно практиковать защитное программирование, избегая любого кода, который использует настройку локального часового пояса компьютера.

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

10

ответ дан Matt Johnson 17 August 2018 в 14:44
поделиться

Если ваш дизайн может вместить его, избегайте локального преобразования времени вместе!

Я знаю, что некоторые из них могут показаться безумными, но подумайте о UX: пользователи начинают приближаться, относительные даты (сегодня, вчера, в следующий понедельник) быстрее, чем абсолютные даты (2010.09.17, пятница 17 сентября). И когда вы думаете об этом больше, точность часовых поясов (и DST) важнее, чем ближе дата к now(), поэтому, если вы можете выразить даты / даты в относительном формате для +/- 1 или 2 недель, остальные даты могут быть UTC, и это не имеет большого значения для 95% пользователей.

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

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

15

ответ дан Matt Kocaj 17 August 2018 в 14:44
поделиться

1

+1 Интересная идея. UTC может быть красивой, o) – Jon Onstott 17 September 2010 в 16:48

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

8

ответ дан paquetp 17 August 2018 в 14:44
поделиться

1

Отличная точка. NTFS не имеет этой проблемы, но некоторые люди все еще используют FAT32 - особенно на USB-ключах. – Matt Johnson 11 January 2013 в 03:22

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

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

Временные интервалы не должны быть полными часовыми отличиями от GMT. Непал +5.45. Есть даже часовые пояса, которые составляют +13. Это означает, что:

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

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

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

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

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

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

22

ответ дан Richard 17 August 2018 в 14:44
поделиться

1

Что касается Израиля - это наполовину верно. Хотя время для изменения ДСТ не является конкретной датой в юлианском календаре - существует правило, основанное на еврейском календаре (произошли изменения в 2014 году). Во всяком случае, общая идея правильна - это может время от времени меняться – Yaron U. 27 April 2014 в 07:31

2

Кроме того, AST = Атлантическое стандартное время. Что касается «лучших советов», это нормально, как отправная точка, но вам нужно прочитать остальную часть этой страницы и произнести небольшую молитву, и вы можете исправить ее на некоторое время. – DavidWalley 14 June 2017 в 20:03

Никогда не полагайтесь только на такие конструкторы, как

new DateTime(int year, int month, int day, int hour, int minute, TimeZone timezone)

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

0

ответ дан sebi 17 August 2018 в 14:44
поделиться

Никогда, никогда не сохраняйте местное время без его UTC-смещения (или ссылки на часовой пояс) - примеры того, как не делать этого, включают FAT32 и struct tm в C.¹

Поймите, что часовой пояс представляет собой комбинацию набора смещений UTC (например, +0100 зимой, +0200 летом), когда происходит переключение (которое может меняться со временем: например, в 1990-х годах ЕС согласовал переход как в последние воскресенья в марте и октябре, в 02:00 по стандартному времени / 03: 00 ДСТ, ранее это отличалось между государствами-членами).

¹ Некоторые реализации struct tm сохраняют смещение UTC, но это не превратило его в стандарт.

0

ответ дан user149408 17 August 2018 в 14:44
поделиться

Если вам удается поддерживать системы баз данных, которые работают с активным DST, внимательно проверьте, нужно ли их отключать во время перехода осенью. Mandy DBS (или другие системы) не любят пропускать одну и ту же точку в (локальном) времени дважды, что точно происходит, когда вы поворачиваете назад осенью. SAP решил это с помощью (IMHO действительно опрятного) решения - вместо того, чтобы возвращать часы, они просто позволяют внутренним часам работать на половине обычной скорости в течение двух часов ...

4

ответ дан vwegert 17 August 2018 в 14:44
поделиться

Другие вопросы по тегам:
database date internationalization timezone timestamp

Похожие вопросы:

53
Хранение изображений в БД - да или нет? - 28 November 2008 05:41

52
Что Ваш № 1 путь состоит в том, чтобы быть осторожным с живой базой данных? - 10 December 2008 19:12

50
Используете ли вы контроль источника для ваших элементов базы данных? [закрыто] - 1 March 2012 21:20

45
Который более быстр/лучший? ВЫБЕРИТЕ * или ВЫБЕРИТЕ column1, colum2, column3, и т.д. - 13 April 2016 04:35

38
Зачем нам нужны объекты сущностей? [закрыто] - 18 June 2016 16:18

36
Что важнее? БД дизайн или кодирование? [закрыто] - 7 July 2011 18:56

31
как рассчитать число Январь месяц между двумя датами с использованием php [duplicate] - 22 March 2017 17:23

score 9 · Answer 1

Держите свои серверы в UTC и убедитесь, что все они настроены для ntp или эквивалента.

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

score -4 · Answer 2

При работе с базами данных (в частности, MySQL , но это относится к большинству баз данных), мне было трудно хранить UTC.

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

Мне было проще просто хранить дату и время сервера в базе данных, а затем позволить базе данных преобразовать сохраненное datetime в UTC (то есть UNIX_TIMESTAMP ()) в операторах SQL. После этого вы можете использовать datetime как UTC в своем коде.

Если у вас есть 100% контроль над сервером и всем кодом, вероятно, лучше изменить часовой пояс сервера на UTC.

Локальное время (время сервера) может быть неоднозначным во время «спада», переход на летнее время. Это не так надежно использовать, как вы описали. Может быть более одного времени UTC, которое может представлять локальное время сервера. — Matt Johnson, 11 January 2013 в 03:13
Местное время отлично, если сервер находится в разумном часовом поясе, то есть не работает DST. — sayap, 2 April 2013 в 11:06

score 4 · Answer 3

Бизнес-правила должны всегда работать в гражданском времени (если только в законодательстве не указано иное). Имейте в виду, что гражданское время - это беспорядок, но это то, что люди используют, поэтому важно то, что важно.

Внутренне сохраняйте отметки времени в чем-то вроде civil-time-seconds-from-epoch. эпоха не имеет особого значения (я предпочитаю Unix epoch ), но это делает вещи проще, чем альтернатива. Представьте, что прыжок-секунд не существует, если вы не делаете то, что действительно нуждается в них (например, спутниковое отслеживание). Отображение временных меток и отображаемого времени является единственной точкой, в которой должны применяться правила DST ; правила часто меняются (на глобальном уровне, несколько раз в год, обвиняют политиков), поэтому вы должны быть уверены, что не скопируете картографирование. База данных Олсона TZ неоценима.

4

ответ дан 2 revs, 2 users 71% 17 August 2018 в 14:44

1

Проблема здесь в том, что гражданское время (иначе календарное время) не отражает должным образом ни одного момента времени. Если вы возьмете подход «секунд-от-эпохи», вы действительно будете учитывать каждый момент, который был пропущен или перемотан для перехода на летнее время? Возможно нет. Эпоха основывается только на UTC или какой-либо другой фиксированной, мгновенной ссылке. – Matt Johnson 11 January 2013 в 03:21
2

@MattJohnson Следовательно, «бизнес-правила» часть. Если в правилах говорится, что что-то происходит в 2:30 утра (или в зависимости от того, какое время), это будет происходить дважды в один день в году и никогда не на один день в году. Это то, что ожидает клиент , если они не уточняют правило. – immibis 16 July 2016 в 16:20

3

Сохранение временных меток в гражданское время может быть очень сложным. Держа его в считанные секунды, так как эпоха еще сложнее, я бы сказал, что это опасно. Я уверен, что есть люди, которые это делают, и, возможно, можно заставить его работать исправно большую часть времени, если вы очень осторожны, но его нельзя считать лучшей практикой или общей рекомендацией. – Steve Summit 2 February 2018 в 17:34

score 6 · Answer 4

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

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

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

score 18 · Answer 5

Для PHP:

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

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

Чтобы справиться с вышеуказанной проблемой, используйте timezonedb pecl package , это функция обновления данных часового пояса PHP. Установите этот пакет так часто, как он обновляется. (Я не уверен, что обновления пакетов соответствуют настройкам Olson точно, но, похоже, они обновляются с частотой, которая, по крайней мере, очень близка к обновлениям Olson.)

score 289 · Answer 6

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

Типы времени

Существует четыре разных раза, рассмотрите:

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

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

Хранение старта / конца временных меток в 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.

Trivia

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

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

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

В этом ответе есть несколько замечательных моментов, я особенно хотел указать на эту часть. «Повторяющееся время: например: ТВ-шоу происходит каждый понедельник в 9 вечера, даже когда изменения DST». Сохранение времени в UTC в БД, а затем преобразование для отображения помогает справиться со многими сложными аспектами работы с часовыми поясами. Однако обработка & quot; повторяющихся событий & quot; что перекрестные барьеры ДСТ становятся намного более жесткими. — Jared Hales, 5 August 2010 в 14:53
+1 для мелочей. Сохранение контента интересно делает эту задачу более приятной, что может привести к повышению производительности :) — Chris, 8 January 2011 в 07:54
В этом ответе много хорошего, но несколько вопросов. 1) Сокращения во многих часовых поясах неоднозначны. см. здесь 2) Не всегда вы хотите сохранить в UTC. В большинстве случаев - да, но контекст имеет значение. В ваших терминах телевизионное время не будет храниться в формате UTC. Кроме того, иногда его противозаконная или противная политика не хранит местное время - в этом случае удобны такие вещи, как DateTimeOffset (или эквивалент). В противном случае, хорошо писать. — Matt Johnson, 11 January 2013 в 03:38
Голландские мелочи выглядят законно. ietf.org/rfc/rfc3339.txt раздел 5.8. На полпути выяснилось, что кто-то тянет нашу ногу. — ruffin, 6 June 2014 в 15:13
Еще один пример для правительств сделать странные вещи: timeanddate.com/news/time/turkey-scraps-dst-2016.html — Ad Infinitum, 21 April 2017 в 11:18

score 3 · Answer 7

Для тех, кто борется с этим на .NET , посмотрите, стоит ли использовать DateTimeOffset и / или TimeZoneInfo.

Если вы хотите использовать Временные зоны IANA / Olson или найти встроенные типы недостаточны для ваших нужд, проверьте Noda Time , который предлагает гораздо более умный API для даты и времени для .NET.

score 24 · Answer 8

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

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

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

Для отображения смещение идеально. Если вы хотите внести изменения, смещения все еще недостаточно. Вы также должны знать часовой пояс, потому что для нового значения может потребоваться другое смещение. — Matt Johnson, 11 January 2013 в 03:30

score 10 · Answer 9

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

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

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

Мое изучение этого: не используйте расчеты даты и времени JavaScript в веб-приложениях, если только вы НЕОБХОДИМО выполнить.

Javascript запускается на клиентской машине, а не на сервере. Базовое datetime для Javascript - это дата-время клиента, а не дата и время сервера. — BalusC, 29 March 2010 в 12:39
Привет, BalusC. Я понимаю это (из моего исходного сообщения: «javacode script на клиенте, который создал дату ...»). Моя проблема заключалась в том, что определенная клиентская машина обрабатывала DST в одну сторону, а некоторые другие по-другому. Поэтому я переместил всю серверную часть обработки, чтобы предотвратить странность браузера — Joon, 31 March 2010 в 09:28
@ Joon - и есть ошибки в реализациях javascript, которые вы не можете обнаружить или разрешить. Так что да, никогда не используйте расчеты даты ECMAScript на клиентской стороне для вещей, которые имеют значение (хотя в противном случае вы можете сделать довольно хорошую работу). — RobG, 16 October 2014 в 03:19

score 53 · Answer 10

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

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

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

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

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

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

score 12 · Answer 11

Я ударил это по двум типам систем: «системы планирования сдвига (например, заводские рабочие)» и «системы управления газом» ...

23 и 25-часовые длинные дни - это боль, чтобы справиться с , так что 8hr сдвиги, которые занимают 7 часов или 9 часов. Проблема заключается в том, что вы обнаружите, что у каждого клиента или даже отдела клиента есть разные правила, которые они создали (часто без документирования) на то, что они делают в этих особых случаях.

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

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

Моя подруга, медсестра, работает ночью, и они должны писать часовой пояс во время переключения DST. Например, 2AM CST против 2AM CDT — Joe Phillips, 5 August 2010 в 03:48
Да, это обычное дело: когда вы вычисляете среднесуточный (средний), вы должны справляться с днями 23, 24 или 25 часов. Как следствие, при вычислении добавьте 1 день, это не добавит 24 часа ! Во-вторых, не пытайтесь создать свой собственный часовой пояс; используйте только API системы. И не забудьте обновить каждую развернутую систему, чтобы получить обновленную базу данных часового пояса . — Alex, 9 October 2013 в 10:44

score 804 · Answer 12

804

ответ дан 30 revs, 18 users 59% 17 August 2018 в 14:44

score 10 · Answer 13

Для Интернета правила не так сложны ...

На стороне сервера, используйте UTC
На стороне клиента используйте Olson Причина: смещения UTC не являются безопасными для летнего времени (например, в Нью-Йорке - EST (UTC - 5 часов) в течение года, EDT (UTC - 4 Hours) в остальной части года). Для определения часового пояса на стороне клиента у вас есть два варианта: 1) Использовать пользовательскую зону (безопаснее) Ресурсы: готовый к использованию в сети Olson tz Выпадающая страница HTML и JSON 2) Авто -detect zone Resource: jsTimezoneDetect

Остальное - это просто UTC / локальное преобразование, используя ваши библиотеки datetime на стороне сервера. Хорошо идти ...

Это хороший совет в качестве отправной точки, но он полностью зависит от приложения. Это может быть хорошо для дружественного веб-сайта, но если в вашем приложении есть какой-либо юридический / юрисдикционный / финансовый аспект, который кто-то может подать в суд (я работал над несколькими), то это чрезмерное упрощение, потому что существуют разные виды " времени ", как указано в других разделах этой страницы. — DavidWalley, 14 June 2017 в 20:13

score 15 · Answer 14

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

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

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

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

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

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

Эти данные могут быть перегорожены из база данных общего доступа tz .

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

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

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

Идея вашей базы данных уже реализована в качестве базы данных Olson. В то время как переход на летнее время создает перекрытие, определяющее часовой пояс, соответствующий дневному свету, может помочь решить проблему. 2:15 EST и 2:15 EDT - это разные времена. Как отмечалось в других сообщениях, указывающих смещение, также устраняется двусмысленность. — BillThor, 4 August 2010 в 00:04
Большая проблема с сохранением собственной базы данных заключается в ее обновлении. Олсон и Windows поддерживаются для вас. У меня было несколько случаев плохого перехода на DST, потому что таблицы устарели. Вытащить их полностью и полагаться на базу данных уровня или базы данных намного надежнее. — Matt Johnson, 11 January 2013 в 03:28
Не создавайте свою собственную базу данных : всегда полагайтесь на API системы! — Alex, 9 October 2013 в 10:54

score 38 · Answer 15

Вам нужно знать о базе данных Olson 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. Как сообщали другие, вы также хотите сохранить данные в фиксированном формате & mdash; Обычно UTC - это выбранный вариант; наряду с записью часового пояса, в котором были созданы данные. Вы можете различать смещение от UTC в момент времени и имя часового пояса; это может изменить ситуацию позже. Кроме того, зная, что в настоящее время 2010-03-28T23: 47: 00-07: 00 (US / Pacific) может или не поможет вам интерпретировать значение 2010-11-15T12: 30 & mdash; который, по-видимому, указан в PST (Pacific Standard Time), а не в PDT (Pacific Daylight Saving Time).

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

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

База данных Olson содержит данные history , что делает ее особенно полезной для обработки DST. Например, он знает, что значение UTC, соответствующее 31 марта 2000 г. в США, не находится в DST, но значение UTC, соответствующее 31 марта 2008 г. в США. — Josh Kelley, 29 March 2010 в 15:29
Консорциум Unicode поддерживает сопоставление идентификаторов зоны Олсона и идентификаторов часовых поясов Windows: unicode.org/repos/cldr-tmp/trunk/diff/supplemental/… — Josh Kelley, 29 March 2010 в 15:30
Обновленная ссылка для страницы Консорциума Юникода: unicode.org/repos/cldr-tmp/trunk/diff/supplemental/… — Span, 2 June 2011 в 05:17
Где можно найти информацию о разборе файлов Olson? Я хочу скомпилировать его в таблицу db, но не могу понять, как читать файлы — shealtiel, 7 September 2011 в 15:09
@gidireich: основная информация найдена с данными, и это непросто понять. Основная документация для него находится на странице zic.8 man (или zic.8.txt). Для получения этой информации вам понадобится файл tzcode2011i.tar.gz, а не файл tzdata2011i.tar.gz, а также файл tzdata2011i.tar.gz. — Jonathan Leffler, 7 September 2011 в 15:46

score 81 · Answer 16

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

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

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

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

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

Джон записывает в своем календаре напоминание о некотором событии в datetime 2019-Jul-27, 10:30:00, TZ = Chile/Santiago (которое имеет смещение GMT- 4, следовательно, это соответствует UTC 2019-Jul-27 14:30:00). Но в какой-то день в будущем страна решит изменить смещение TZ на 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).

Еще один момент для рассмотрения, который я не видел в API, заключается в том, что даже когда заданы время и часовой пояс, существует, по меньшей мере, два правдоподобных значения, например. & Quot; 13: 00: 00EDT & Quot ;. Это может быть ссылка на то, что, как известно, произошло в 13:00 по местному времени, которое, как полагали, было восточным дневным светом или что-то, что, как известно, произошло в тот момент, когда восточное время достигло 13:00, что, как полагают, произошли в месте, где наблюдалось восточное летнее время. Если у вас много временных меток, где информация о часовом поясе может быть неправильной (например, файлы цифровой камеры) ... — supercat, 29 October 2013 в 19:04
... зная, будут ли они отражать точное местное время или глобальное время, могут быть важны при определении того, как их исправить. — supercat, 29 October 2013 в 19:04
Ясно, что Джон хочет, чтобы А), потому что люди идут на работу в 8:30, независимо от того, что такое DST или часовой пояс. Если они займутся DST, они приступят к работе в 8:30, когда они выйдут с DST, они отправятся на работу в 8:30. Если страна решит переехать в другой часовой пояс, они отправятся на работу в 8:30 — Gianluca Ghettini, 9 March 2017 в 17:54

score 2 · Answer 17

Просто хотел указать на две вещи, которые кажутся неточными или, по крайней мере, запутанными:

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

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

При хранении временных меток включайте локальное смещение по времени (включая смещение DST).

Временная метка всегда отображается в GMT и, следовательно, не имеет смещения.

2

ответ дан Alix Axel 17 August 2018 в 14:44

1

Местное смещение по времени позволит вам воссоздать исходное «время на стене», события. Если вы не сохраните это дополнительное поле, эти данные будут потеряны. – nogridbag 16 April 2012 в 19:33
2

Да, за исключением UTC и GMT смещения являются обратными. Например, UTC-0700 совпадает с GMT + 0700. На самом деле, все цифровые данные должны использовать UTC в эти дни. – Matt Johnson 13 September 2012 в 20:36
3

@Matt: вы уверены, что UTC и GMT смещения являются обратными? где я могу это прочитать? – Reto Höhener 16 February 2013 в 16:22
4

На самом деле, я думаю, что раньше был неправильным. GMT и UTC не перевернуты сами. Это то, что есть реализации, которые показывают их в обратном порядке, такие как база данных IANA / Olson / TZDB. См. здесь . Другая область, которую вы видите смещения в обратном, - это функция getTimezoneOffset () javascript. – Matt Johnson 16 February 2013 в 19:49
5

@MattJohnson: Это хаки и должны быть отменены. – Alix Axel 17 February 2013 в 00:55

score 2 · Answer 18

Голосование Тома Скотта о часовых поясах на YouTube на канале Computerphile также имеет приятное и интересное описание темы. Примеры включают:

Самоа (остров в Тихом океане) переводит свой часовой пояс вперед на 24 часа, чтобы облегчить торговлю с Австралией и Новой Зеландией
на Западном берегу, где 2 популяции людей следуют за разными часовыми поясами,
изменения 18-го века от юлианского календаря до григорианского календаря (что произошло в XX веке в России).

score 1 · Answer 19

На самом деле kernel32.dll не экспортирует SystemTimeToTzSpecificLocation. Однако он экспортирует следующие два: SystemTimeToTzSpecificLocalTime и TzSpecificLocalTimeToSystemTime ...

score 1 · Answer 20

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

Несколько лет назад операционная система Android использовала спутники GPS для получения информации о времени UTC, но проигнорировала тот факт, что спутники GPS не используют скачки секунд. Никто не заметил, пока не возникла путаница в канун Нового года, когда пользователи телефонов Apple и пользователи телефонов Android сделали свои обратные отсчеты примерно на 15 секунд друг от друга.

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

score 2 · Answer 21

Вот мой опыт: -

(не требует сторонней библиотеки)

На стороне сервера сохраняйте время в формате UTC, чтобы вся дата / time в базе данных находятся в одном стандарте независимо от местоположения пользователей, серверов, часовых поясов или DST.
На уровне пользовательского интерфейса или в сообщениях электронной почты, отправленных пользователю, вам нужно показать время в соответствии с пользователем. В этом случае вам необходимо иметь смещение часового пояса пользователя, чтобы вы могли добавить это смещение в значение UTC базы данных, которое приведет к локальному времени пользователя. Вы можете либо принять смещение часового пояса пользователя при их регистрации, либо автоматически обнаружить их на веб-и мобильных платформах. Для веб-сайтов функция JavaScript getTimezoneOffset () является стандартной версией версии 1.0 и совместима со всеми браузерами. (Ссылка: http://www.w3schools.com/jsref/jsref_getTimezoneOffset.asp )

Это не работает, если вы рассматриваете изменения DST. getTimezoneOffset возвращает смещение для даты и времени, когда вы его вызываете. Это смещение может измениться, когда часовой пояс переходит в или из летнего времени. См. «Часовой пояс! = Смещение». в тег часовой пояс wiki . — Matt Johnson, 22 May 2015 в 18:21
Если вы хотите сохранить сигнал тревоги, например «сделать что-то в 10:00», вы не сможете сохранить его в UTC из-за сдвигов DST. Вы должны хранить его относительно местного времени. — Alex, 23 May 2017 в 12:31

score 5 · Answer 22

Выход PHP `DateTimeZone::listAbbreviations()`

Этот метод PHP возвращает ассоциативный массив, содержащий некоторые «основные» часовые пояса (например, CEST), которые сами по себе содержат более конкретные «географические» (например, Европа / Амстердам).

Если вы используете эти часовые пояса и их информацию о смещении / DST, чрезвычайно важно реализовать следующее:

Кажется, что все разные конфигурации смещения / DST (включая исторические конфигурации) каждого часового пояса включены!

Например, Европа / Амстердам можно найти шесть раз на выходе этой функции. Два события (смещение 1172/4772) относятся к Амстердамскому времени, использованному до 1937 года; два (1200/4800) относятся к тому времени, которое использовалось между 1937 и 1940 годами; и два (3600/4800) относятся к времени, используемому с 1940 года.

Поэтому вы не можете полагаться на информацию о смещении / DST, возвращаемую этой функцией , как правильную / в use!

Если вы хотите узнать текущее смещение / DST определенного часового пояса, вам нужно будет сделать что-то вроде этого:

<?php
$now = new DateTime(null, new DateTimeZone('Europe/Amsterdam'));
echo $now->getOffset();
?>

score 3 · Answer 23

Используете ли вы платформу .NET? Если да, позвольте мне представить вам тип DateTimeOffset , добавленный с .NET 3.5.

Эта структура содержит как DateTime, так и смещение (TimeSpan), что задает разницу между датой и временем экземпляра DateTimeOffset и скоординированным универсальным временем (UTC).

Статический метод DateTimeOffset.Now возвращает экземпляр DateTimeOffset, состоящий из текущего (локального) время и местное смещение (как определено в региональной информации операционной системы).
Статический метод DateTimeOffset.UtcNow возвращает экземпляр DateTimeOffset, состоящий из текущего времени в UTC (как если бы вы были в Гринвич).

Другими полезными типами являются классы TimeZone и TimeZoneInfo .

score 10 · Answer 24

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

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

Код на стороне сервера, включая веб-сайты, должен никогда ожидать локальный часовой пояс сервера

На некоторых языках локальный часовой пояс может легко входить в код приложения. Например, метод DateTime.ToUniversalTime в .NET будет конвертировать из в локальный часовой пояс в UTC, а свойство DateTime.Now возвращает текущее время в локальном часовом поясе. Кроме того, конструктор Date в JavaScript использует локальный часовой пояс компьютера. Есть много других подобных примеров. Важно практиковать защитное программирование, избегая любого кода, который использует настройку локального часового пояса компьютера.

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

score 15 · Answer 25

Если ваш дизайн может вместить его, избегайте локального преобразования времени вместе!

Я знаю, что некоторые из них могут показаться безумными, но подумайте о UX: пользователи начинают приближаться, относительные даты (сегодня, вчера, в следующий понедельник) быстрее, чем абсолютные даты (2010.09.17, пятница 17 сентября). И когда вы думаете об этом больше, точность часовых поясов (и DST) важнее, чем ближе дата к now(), поэтому, если вы можете выразить даты / даты в относительном формате для +/- 1 или 2 недель, остальные даты могут быть UTC, и это не имеет большого значения для 95% пользователей.

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

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

+1 Интересная идея. UTC может быть красивой, o) — Jon Onstott, 17 September 2010 в 16:48

score 8 · Answer 26

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

8

ответ дан paquetp 17 August 2018 в 14:44

1

Отличная точка. NTFS не имеет этой проблемы, но некоторые люди все еще используют FAT32 - особенно на USB-ключах. – Matt Johnson 11 January 2013 в 03:22

score 22 · Answer 27

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

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

Временные интервалы не должны быть полными часовыми отличиями от GMT. Непал +5.45. Есть даже часовые пояса, которые составляют +13. Это означает, что:

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

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

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

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

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

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

Что касается Израиля - это наполовину верно. Хотя время для изменения ДСТ не является конкретной датой в юлианском календаре - существует правило, основанное на еврейском календаре (произошли изменения в 2014 году). Во всяком случае, общая идея правильна - это может время от времени меняться — Yaron U., 27 April 2014 в 07:31
Кроме того, AST = Атлантическое стандартное время. Что касается «лучших советов», это нормально, как отправная точка, но вам нужно прочитать остальную часть этой страницы и произнести небольшую молитву, и вы можете исправить ее на некоторое время. — DavidWalley, 14 June 2017 в 20:03

score 0 · Answer 28

Никогда не полагайтесь только на такие конструкторы, как

 new DateTime(int year, int month, int day, int hour, int minute, TimeZone timezone)

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

score 0 · Answer 29

Никогда, никогда не сохраняйте местное время без его UTC-смещения (или ссылки на часовой пояс) - примеры того, как не делать этого, включают FAT32 и struct tm в C.¹
Поймите, что часовой пояс представляет собой комбинацию набора смещений UTC (например, +0100 зимой, +0200 летом), когда происходит переключение (которое может меняться со временем: например, в 1990-х годах ЕС согласовал переход как в последние воскресенья в марте и октябре, в 02:00 по стандартному времени / 03: 00 ДСТ, ранее это отличалось между государствами-членами).

¹ Некоторые реализации struct tm сохраняют смещение UTC, но это не превратило его в стандарт.

score 4 · Answer 30

Если вам удается поддерживать системы баз данных, которые работают с активным DST, внимательно проверьте, нужно ли их отключать во время перехода осенью. Mandy DBS (или другие системы) не любят пропускать одну и ту же точку в (локальном) времени дважды, что точно происходит, когда вы поворачиваете назад осенью. SAP решил это с помощью (IMHO действительно опрятного) решения - вместо того, чтобы возвращать часы, они просто позволяют внутренним часам работать на половине обычной скорости в течение двух часов ...

Каков наилучший способ хранения международных дат в базе данных? [Дубликат]

30 ответов

Типы времени

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

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

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

Клиенты

Trivia

Выход PHP DateTimeZone::listAbbreviations()

Похожие вопросы:

Выход PHP `DateTimeZone::listAbbreviations()`