Как лучше всего представить правила летнего времени?

Question

Мне нужно сохранить в базе данных правила перехода на летнее время (летнее время) для разных регионов мира.У меня уже есть способ хранения регионов и субрегионов (поэтому весь «половина Австралии»/Аризона/Навахо проблема решена), но мне интересно, какая схема будет наиболее эффективной для этого.Два варианта, как я их вижу:

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

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

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

Есть ли у кого-нибудь опыт сделать что-то подобное?Аналогично, есть ли у кого-нибудь блестящие варианты, которые я, возможно, пропустил?

Answer 1

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

Вот почему все поставщики ОС вносят изменения в файлы часовых поясов один или два раза в год — им приходится это делать, потому что они не могут программно генерировать 100% точный файл.

Answer 2

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

Answer 3

Одним из лучших источников информации о правилах часовых поясов является база данных Олсона, которую можно получить на сайте elsie.nci.nih.gov.На сентябрь 2008 года текущая версия данных была tzdata2008f.tar.gz, текущая версия кода — tzcode2008e.tar.gz (и да, код не всегда освобождался при выпуске данных).Обычно это является источником информации для многих других систем (включая, в частности, информацию Oracle).Также доступен список рассылки.Как видите, в 2008 году было шесть версий данных;На моей машине скрываются копии 2005r, 2006l, 2007k, поэтому ситуация может меняться довольно часто.

В настоящее время (март 2017 г.) база данных Олсона доступна в IANA — см. https://iana.org/time-zones и ftp://ftp.iana.org/tz (особенно ftp://ftp.iana.org/tz/releases).

Существует также общий репозиторий данных локали. КЛДР который также содержит информацию о часовых поясах.

Answer 4

СУБД Oracle автоматически сделает это за вас.Дата хранится во внутреннем представлении (представим себе UMT ради аргумента) и форматируется в соответствии с правилами часового пояса при преобразовании в строку.

Это также решает спор о том, что делать во время изменений во времени.И.Е.когда вы переводите часы назад на пол часа, на самом деле в один и тот же день происходит 2 случая 3:25 утра.