Рассчитать переход на летнее время (DST) на уровне SQL / базы данных

Question

Мое местоположение в Сиднее, Австралия . Даты, которые я объясняю, будут в формате даты Великобритании или Австралии.

Обратите внимание на следующее:

• 2010-04-15 04: 30: 00.000 => 15/04/2010 14:30:00 EST (формат даты в Великобритании - добавление 10 часов)
• 2010-11-05 01: 00: 00.000 => 05/11/2010 12:00:00 EST (формат даты в Великобритании - добавление 11 часов)

Оба эти времени извлекаются из базы данных в формате UTC, а затем рассчитывается на веб-уровне , применимо ли +10 или +11 час.

В Австралии даты перехода на летнее время (DST) меняются год от года. Даты перехода обычно - начало апреля и конец октября.

Итак, насколько точным будет веб-расчет? Если в этом году датой перехода будет несколько дней спустя (скажем, 03/04/2010), но расчет в Интернете будет основан на фиксированной дате (например, 01/04/2010), не будет ли это означать, что промежуточные дни выключено на 1 час при отображении (из-за фиксированного характера расчета для определенного дня месяца)?

Я полагаю, что даты перехода не определены заранее и фактически объявлены общественности. Это предположение верно?

Если нет (это означает, что даты перехода на летнее время предварительно определены), смогу ли я выполнить вычисления за пределами веб-уровня (на SQL / уровне базы данных )?

База данных SQL Server 2005 , и я использую Язык определения отчета (RDL) для отображения полей в формате UTC. Если уровень SQL / базы данных не самый лучший способ, как мне рассчитать +10 или +11 и соответственно отформатировать время, чтобы показать правильное время?

Спасибо.

Answer 1

База данных - плохой выбор: в ней меньше информации, чем в c # или .net, чтобы ее решить..net использует реестр, который периодически обновляется патчами.В SQL Server должна быть таблица с диапазонами дат и смещениями.

Переходы фиксируются из-за расписания (полеты, поезда и т. Д.).IIRC недавно изменилась только один раз за короткое время в Австралии для некоторых Олимпийских игр, и это вызвало хаос во всем мире.В 2007 году США изменилось , но это было известно заранее.

По фиксированному типу это «последнее воскресенье», даже если дата меняется.это в веб-коде: БД не знает, например, где находится ваш абонент, веб-сайт может это решить.

Answer 2

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

Если вы используете UTC, тогда все ваши арифметические данные должны использовать UTC. В базе данных. В настоящее время он использует сохраненный UTC, а затем конвертирует на каком-то (неважно, второй уровень или третий) другой слой; какая-то другая библиотека. Половина UTC, и Половина чего-то еще. Рассматривали ли вы исторические даты, например, что такое DATEDIFF () между 15 февраля 2010 года и сегодня?

Это устраняет беспокойство по поводу DST в Австралии или Гренландии .; и касайтесь того, в какую дату / время произойдет переключение. Все используют Гринвичское среднее время для этого конкретного дня.

Делайте все, что вы встречаетесь с арифметикой в ​​БД, в UTC. И отобразить результат (только) в местном часовом поясе, который, как у вас, является веб-слоем, основанным на пользователе.

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

Answer 3

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

В MySQL есть CONVERT_TZ (), я не знаю, что есть в других СУБД.