Вы можете использовать enumerated()
, чтобы получить как индекс, так и значение во время цикла:
for (index, element) in masterA.enumerated() {
if index % 2 == 0 {
evenA.append(element)
} else {
oddA.append(element)
}
}
Это будет хранить каждый element
из masterA
с нечетным индексом в oddA
и каждый элемент с четным индексом в evenA
.
Держите свои серверы в UTC и убедитесь, что все они настроены для ntp или эквивалента.
UTC избегает проблем с летним временем, а серверы вне синхронизации могут вызывать непредсказуемые результаты некоторое время для диагностики.
При работе с базами данных (в частности, MySQL , но это относится к большинству баз данных), мне было трудно хранить UTC.
Мне было проще просто хранить дату и время сервера в базе данных, а затем позволить базе данных преобразовать сохраненное datetime в UTC (то есть UNIX_TIMESTAMP ()) в операторах SQL. После этого вы можете использовать datetime как UTC в своем коде.
Если у вас есть 100% контроль над сервером и всем кодом, вероятно, лучше изменить часовой пояс сервера на UTC.
Бизнес-правила должны всегда работать в гражданском времени (если только в законодательстве не указано иное). Имейте в виду, что гражданское время - это беспорядок, но это то, что люди используют, поэтому важно то, что важно.
Внутренне сохраняйте отметки времени в чем-то вроде civil-time-seconds-from-epoch. эпоха не имеет особого значения (я предпочитаю Unix epoch ), но это делает вещи проще, чем альтернатива. Представьте, что прыжок-секунд не существует, если вы не делаете то, что действительно нуждается в них (например, спутниковое отслеживание). Отображение временных меток и отображаемого времени является единственной точкой, в которой должны применяться правила DST ; правила часто меняются (на глобальном уровне, несколько раз в год, обвиняют политиков), поэтому вы должны быть уверены, что не скопируете картографирование. База данных Олсона TZ неоценима.
Еще одна вещь, убедитесь, что на серверах установлен обновленный патч.
У нас была ситуация в прошлом году, когда наши времена были неизменно на один час в течение трех недель для Североамериканских пользователей, хотя мы использовали систему на базе UTC.
Оказывается, в конце концов это были серверы. Они просто нуждались в обновленном исправлении ( Windows Server 2003 ).
Для PHP:
Класс DateTimeZone в PHP> 5.2 уже основан на Olson DB, о котором говорят другие, поэтому, если вы делаете преобразования часовых поясов в PHP, а не в БД, вы освобождаетесь от работая с (труднодоступными) файлами Olson.
Тем не менее, PHP не обновляется так часто, как Olson DB, поэтому просто использование PHP-запросов часового пояса может оставить вам устаревшую информацию о DST и повлиять на правильность ваших данных. Хотя этого не ожидается часто, это может произойти, и будет , если у вас есть большая база пользователей по всему миру.
Чтобы справиться с вышеуказанной проблемой, используйте timezonedb pecl package , это функция обновления данных часового пояса PHP. Установите этот пакет так часто, как он обновляется. (Я не уверен, что обновления пакетов соответствуют настройкам Olson точно, но, похоже, они обновляются с частотой, которая, по крайней мере, очень близка к обновлениям Olson.)
Я не уверен, что я могу добавить к ответам выше, но вот несколько моментов от меня:
Существует четыре разных раза, рассмотрите:
Существует также историческое / альтернативное время , Это раздражает, потому что они не могут вернуться к стандартному времени. Например: юлианские даты, даты по лунному календарю на Сатурне, календарь Клингонов.
Хранение старта / конца временных меток в UTC работает хорошо. Для 1 вам потребуется имя часового пояса + смещение, сохраненное вместе с событием. Для 2 вам нужен локальный идентификатор времени, хранящийся в каждом регионе, и локальное имя часового пояса + смещение, хранящееся для каждого зрителя (это можно получить из IP-адреса, если вы находитесь в хрусте). Для 3, сохранить в UTC секунд и нет необходимости в часовых поясах. 4 является частным случаем 1 или 2 в зависимости от того, является ли это глобальным или локальным событием, но вам также необходимо сохранить , созданную на отметке времени , чтобы вы могли определить, изменилось ли определение часового пояса до или после этого событие было создано. Это необходимо, если вам нужно показать исторические данные.
Примером приведенного выше может быть:
Игра в финале Кубка мира по футболу произошла на Юге Африка (UTC + 2 - SAST) 11 июля 2010 года в 19:00 UTC.
blockquote>С помощью этой информации мы можем исторически определить точное время, когда финал 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.
blockquote>Хорошо, я думаю, что все готово.
DateTimeOffset
(или эквивалент). В противном случае, хорошо писать.
– Matt Johnson
11 January 2013 в 03:38
Для тех, кто борется с этим на .NET , посмотрите, стоит ли использовать DateTimeOffset
и / или TimeZoneInfo
.
Если вы хотите использовать Временные зоны IANA / Olson или найти встроенные типы недостаточны для ваших нужд, проверьте Noda Time , который предлагает гораздо более умный API для даты и времени для .NET.
В общем случае включите локальное смещение по времени (включая смещение DST) в сохраненные временные метки: только UTC недостаточно, если вы позже захотите отобразить временную метку в своем исходном часовом поясе (и настройке DST).
Имейте в виду, что смещение не всегда является целым числом часов (например, индийское стандартное время - UTC + 05: 30).
Например, подходящими форматами являются кортеж (время unix, смещение в минутах) или ISO 8601 .
Недавно у меня возникла проблема в веб-приложении, где на Ajax пост-обратно дата-время, возвращающееся к моему серверному коду, отличалось от того, что было подано в прошлом.
Скорее всего, это нужно было сделать с моим кодом JavaScript на клиенте, который создал дату отправки назад клиенту в виде строки, поскольку JavaScript настраивался для изменения часового пояса и летнего времени, а в некоторых браузерах расчет того, когда применять летнее время, по-видимому, отличался от другие.
В конце я решил полностью удалить расчеты даты и времени на клиенте и отправил обратно на мой сервер на целочисленный ключ, который затем переводился на дату на сервере, чтобы обеспечить согласованность преобразования.
Мое изучение этого: не используйте расчеты даты и времени JavaScript в веб-приложениях, если только вы НЕОБХОДИМО выполнить.
Сделать четкое архитектурное разделение проблем - точно знать, какой уровень взаимодействует с пользователями, и изменять дату-время для / из канонического представления (UTC). Не-UTC дата-время - презентация (следующая локальная часовая зона пользователей), время UTC - это модель (остается уникальной для внутренних и средних уровней).
Кроме того, решайте, какова ваша фактическая аудитория, t должен служить, и где вы рисуете линию. Не трогайте экзотические календари, если у вас на самом деле нет важных клиентов, а затем рассмотрите отдельные серверы (серверы), ориентированные на пользователя, только для этого региона.
Если вы можете приобретать и поддерживать местоположение пользователя, используйте место для систематической даты (например, .NET-культура или SQL-таблица), но предоставляют возможность конечным пользователям выбирать переопределения, если для ваших пользователей критически важна дата-время.
Если есть исторические обязательства по аудиту (например, точно, когда Jo в AZ заплатил счет 2 года назад в сентябре), затем сохраните как UTC, так и местное время для записи (ваши таблицы преобразования будут меняться в течение времени).
Определите время референтного времени зона для данных, которые поступают в виде файлов, например, веб-сервисов и т. д. У компании East Coast есть центр обработки данных в CA - вам нужно спросить и узнать, что они используют в качестве стандарта, вместо того, чтобы предполагать тот или иной.
Не доверяйте смещениям временного диапазона, встроенным в текстовое представление даты, и не принимайте их для разбора и следования им , Вместо этого всегда запрашивайте, чтобы часовой пояс и / или контрольная зона были явно определены. Вы можете легко получать время с помощью PST-смещения, но время на самом деле является EST, поскольку это контрольное время клиента и записи были просто экспортированы на сервере, который находится в PST.
Я ударил это по двум типам систем: «системы планирования сдвига (например, заводские рабочие)» и «системы управления газом» ...
23 и 25-часовые длинные дни - это боль, чтобы справиться с , так что 8hr сдвиги, которые занимают 7 часов или 9 часов. Проблема заключается в том, что вы обнаружите, что у каждого клиента или даже отдела клиента есть разные правила, которые они создали (часто без документирования) на то, что они делают в этих особых случаях.
Некоторые вопросы лучше не задавать до тех пор, пока они не оплатят программное обеспечение «с полки». Очень редко можно найти клиента, который думает об этом типе проблемы перед покупкой программного обеспечения.
Я думаю, что во всех случаях вам нужно записывать время в UTC и конвертировать в / из местного времени, прежде чем хранить дату /время. Однако даже знать, какое время занимает определенное время, может быть затруднено с летнего времени и часовых поясов.
Для Интернета правила не так сложны ...
Остальное - это просто UTC / локальное преобразование, используя ваши библиотеки datetime на стороне сервера. Хорошо идти ...
Пока я не пробовал, подход к настройкам часовых поясов, которые я нашел бы убедительными, был бы следующим:
TZOffsets
с тремя столбцами: RegionClassId, StartDateTime и OffsetMinutes (int, в минутах). В таблице сохраните список дат и времени , когда местное время изменилось и на сколько. Количество регионов в таблице и количество дат будет зависеть от того, какой диапазон дат и областей мира вам необходимо поддерживать. Подумайте об этом, как будто это «историческая» дата, хотя даты должны включать будущее в какой-то практический предел.
Когда вам нужно вычислить местное время любого времени UTC, просто выполните следующее:
SELECT DATEADD('m', SUM(OffsetMinutes), @inputdatetime) AS LocalDateTime
FROM TZOffsets
WHERE StartDateTime <= @inputdatetime
AND RegionClassId = @RegionClassId;
Возможно, вы захотите кэшировать эту таблицу в своем приложении и использовать LINQ или некоторые аналогичные средства для выполнения запросов, а не для попадания в базу данных.
Эти данные могут быть перегорожены из база данных общего доступа tz .
Преимущества и сноски этого подхода:
Теперь единственным недостатком этого подхода или любого другого является то, что преобразования из местное время до GMT не идеальны, так как любое изменение DST, которое имеет отрицательное смещение к часам , повторяет заданное местное время. Я просто боюсь, что это простой способ справиться с этим, что является одной из причин сохранения местных времен - это, во-первых, плохая новость.
Вам нужно знать о базе данных 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
.
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).
Просто хотел указать на две вещи, которые кажутся неточными или, по крайней мере, запутанными:
Всегда сохраняйте время в соответствии с единым стандартом, на который не влияет дневная экономия. GMT и UTC упоминаются разными людьми, хотя чаще всего упоминается UTC.
blockquote>Для почти всех практических вычислительных целей UTC, по сути, является GMT. Если вы не видите временные метки с дробной секунды, вы имеете дело с GMT, что делает это различие избыточным.
При хранении временных меток включайте локальное смещение по времени (включая смещение DST).
blockquote>Временная метка всегда отображается в GMT и, следовательно, не имеет смещения.
Голосование Тома Скотта о часовых поясах на YouTube на канале Computerphile также имеет приятное и интересное описание темы. Примеры включают:
На самом деле kernel32.dll не экспортирует SystemTimeToTzSpecificLocation. Однако он экспортирует следующие два: SystemTimeToTzSpecificLocalTime и TzSpecificLocalTimeToSystemTime ...
Только один пример, чтобы доказать, что время обработки - огромный беспорядок, описанный, и что вы никогда не сможете успокаиваться. В нескольких точках на этой странице прыжки-секунды были проигнорированы.
Несколько лет назад операционная система Android использовала спутники GPS для получения информации о времени UTC, но проигнорировала тот факт, что спутники GPS не используют скачки секунд. Никто не заметил, пока не возникла путаница в канун Нового года, когда пользователи телефонов Apple и пользователи телефонов Android сделали свои обратные отсчеты примерно на 15 секунд друг от друга.
Я думаю, что с тех пор он исправлен, но вы никогда не знаете, когда эти «мелкие детали» вернутся, чтобы преследовать вас.
Вот мой опыт: -
(не требует сторонней библиотеки)
getTimezoneOffset
возвращает смещение для даты и времени, когда вы его вызываете. Это смещение может измениться, когда часовой пояс переходит в или из летнего времени. См. «Часовой пояс! = Смещение». в тег часовой пояс wiki .
– Matt Johnson
22 May 2015 в 18:21
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();
?>
Используете ли вы платформу .NET? Если да, позвольте мне представить вам тип DateTimeOffset , добавленный с .NET 3.5.
Эта структура содержит как DateTime
, так и смещение (TimeSpan
), что задает разницу между датой и временем экземпляра DateTimeOffset
и скоординированным универсальным временем (UTC).
DateTimeOffset.Now
возвращает экземпляр DateTimeOffset
, состоящий из текущего (локального) время и местное смещение (как определено в региональной информации операционной системы). DateTimeOffset.UtcNow
возвращает экземпляр DateTimeOffset
, состоящий из текущего времени в UTC (как если бы вы были в Гринвич). Другими полезными типами являются классы TimeZone и TimeZoneInfo .
Когда дело касается приложений, запущенных на сервере , включая веб-сайты и другие серверные службы, настройки часового пояса сервера должны игнорироваться приложением.
Общий совет - установить часовой пояс сервера в UTC. Это действительно хорошая передовая практика, но она существует как бандаж для приложений, которые не следуют другим лучшим практикам. Например, служба может записывать файлы журналов с локальными временными метками вместо временных меток, основанных на UTC, тем самым создавая неоднозначность во время переходного периода перехода на летнее время. Установка часового пояса сервера в UTC исправит приложение . Однако реальное исправить было бы для приложения для ведения журнала с использованием UTC для начала.
Код на стороне сервера, включая веб-сайты, должен никогда ожидать локальный часовой пояс сервера
На некоторых языках локальный часовой пояс может легко входить в код приложения. Например, метод DateTime.ToUniversalTime
в .NET будет конвертировать из в локальный часовой пояс в UTC, а свойство DateTime.Now
возвращает текущее время в локальном часовом поясе. Кроме того, конструктор Date
в JavaScript использует локальный часовой пояс компьютера. Есть много других подобных примеров. Важно практиковать защитное программирование, избегая любого кода, который использует настройку локального часового пояса компьютера.
Зарезервируйте с использованием локального часового пояса для клиентского кода, такого как настольные приложения, мобильные приложения и клиент- боковой JavaScript.
Если ваш дизайн может вместить его, избегайте локального преобразования времени вместе!
Я знаю, что некоторые из них могут показаться безумными, но подумайте о UX: пользователи начинают приближаться, относительные даты (сегодня, вчера, в следующий понедельник) быстрее, чем абсолютные даты (2010.09.17, пятница 17 сентября). И когда вы думаете об этом больше, точность часовых поясов (и DST) важнее, чем ближе дата к now()
, поэтому, если вы можете выразить даты / даты в относительном формате для +/- 1 или 2 недель, остальные даты могут быть UTC, и это не имеет большого значения для 95% пользователей.
Таким образом, вы можете хранить все даты в UTC и выполнять относительные сравнения в UTC и просто показывать даты UTC пользователя вне вашего порога относительной даты.
Это также может относиться и к пользовательскому вводу (но обычно более ограниченным образом). Выбор из раскрывающегося списка, который имеет только {Вчера, сегодня, завтра, в следующий понедельник, следующий четверг), намного проще и проще для пользователя, чем выбор даты. Сборщики даты являются одними из наиболее болевых компонентов, заполняющих форму. Конечно, это не сработает для всех случаев, но вы можете видеть, что для его создания требуется только немного умного дизайна.
Будьте внимательны при работе с отметками времени, хранящимися в файловой системе FAT32, - они всегда сохраняются в локальных координатах времени (включая DST - см. статью msdn ). Сгорел на этом.
Пересечение границы «компьютерного времени» и «времени людей» - это кошмар. Главное, что нет никаких стандартов для правил, регулирующих часовые пояса и летнее время. Страны могут свободно изменять свой часовой пояс и правила летнего времени в любое время, и они это делают.
Некоторые страны, например. Израиль, Бразилия, каждый год решают, когда им нужно летнее время, поэтому невозможно заранее знать, когда (если) будет действовать 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 в всего).
Никогда не полагайтесь только на такие конструкторы, как
new DateTime(int year, int month, int day, int hour, int minute, TimeZone timezone)
Они могут генерировать исключения, когда определенное время не существует из-за DST. Вместо этого создайте свои собственные методы для создания таких дат. В них улавливаются любые исключения, возникающие из-за DST, и корректировка времени требуется с смещением перехода. DST может происходить в разные даты и в разные часы (даже в полночь для Бразилии) в соответствии с часовым поясом.
struct tm
в C.¹ ¹ Некоторые реализации struct tm
сохраняют смещение UTC, но это не превратило его в стандарт.
Если вам удается поддерживать системы баз данных, которые работают с активным DST, внимательно проверьте, нужно ли их отключать во время перехода осенью. Mandy DBS (или другие системы) не любят пропускать одну и ту же точку в (локальном) времени дважды, что точно происходит, когда вы поворачиваете назад осенью. SAP решил это с помощью (IMHO действительно опрятного) решения - вместо того, чтобы возвращать часы, они просто позволяют внутренним часам работать на половине обычной скорости в течение двух часов ...