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

Question

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

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

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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