Который сейчас час? Есть много способов ответить на этот вопрос, но можно ли сформулировать однозначное абсолютное время, понятное каждому в любом контексте? (Да, очевидно, это очень легко.)
В Singularity каждый день мы получаем сотни тысяч точек данных, представляющих ежеминутную активность электрической сети из источников по всему миру. Точное определение того, когда произошло каждое событие, имеет первостепенное значение. Но вместо того, чтобы принять общепризнанный стандарт, многие из наших источников кажутся более неравнодушными к специальной теории относительности Эйнштейна — два разных наблюдателя не могут прийти к единому мнению относительно концепции абсолютного времени, так зачем пытаться? Вот четыре всадника плохих временных меток.
Нет часового пояса
Самая распространенная проблема — простое отсутствие часового пояса. Отметка времени, такая как 2023-01-06 14:57, от организации, отвечающей за инфраструктуру, которая охватывает три часовых пояса, имеет такое же значение, как и 2023-01-06 mid-afternoon. Мы вынуждены сделать предположение.
Что еще хуже, один источник предоставляет незонированные временные метки, которые оказываются в EST и только EST. Несмотря на то, что эта организация проживает в районе, который переключается на EDT в течение полугода, эта организация продолжает отчитываться в EST в течение всего периода перехода на летнее время, что приводит к появлению забавного жука, похожего на сурка, который показывает свое лицо только два раза в год.
Исправление. Просто укажите часовой пояс. (EST) — это всего лишь дополнительные 5 символов. Если вы чувствуете себя действительно смелым, используйте метку времени ISO 8601 со смещением UTC, например -05:00.
Настоящее решение. Свяжитесь с ответственной организацией и поиграйте в веселую игру с телефонной меткой, пока они, наконец, не сломаются и не сообщат вам часовой пояс.
Дневного сбережения
Как вы, возможно, знаете, переход на летнее время или летнее время — это заговор с целью поддержать индустрию программного обеспечения, создавая бесчисленные часы ненужной работы. В часовом поясе UTC нет перехода на летнее время, и каждое мгновение следует за последним в предсказуемом, но монотонном параде. К счастью для наших инженеров, большинство сетевых операторов предпочитают сообщать данные с часовыми поясами, которые соответствуют летнему времени, где целые часы могут появляться или исчезать по желанию. Как это можно представить в данных? Так рад, что вы спросили.
Один поставщик данных предлагает электронную таблицу Excel со столбцом для каждого 15-минутного интервала каждого дня. Когда мы прыгаем вперед в марте, есть блок пустых ячеек для пропущенного часа. Куда это делось? Перейдем к ноябрю, и есть четыре новых временных метки (DST) для повторяющегося часа осени: 01:15 (DST), 01:30 (DST), 01:45 (DST), 02:00 (DST).
«Нет проблем, — слышу я, вы думаете, — я просто воспользуюсь своей удобной библиотекой часовых поясов, чтобы преобразовать это в UTC».
pytz.timezone("US/Central").localize(parsed_date, is_dst=True).astimezone(utc)
НЕТ! НЕПРАВИЛЬНЫЙ! Вы попались в их ловушку. Нет такой вещи, как 02:00 (DST) — повторяющийся час летнего времени только 01:00-01:59. Здесь 02:00 (DST) фактически представляет собой конец 15-минутного интервала с 01:45 (DST)по 01:59 (DST), поэтому вам нужно будет вычесть 15 минут, прежде чем вы сможете преобразовать часовой пояс в нормальный. Это не указано ни в одной документации, но было бы интересно, если бы это было так?
Исправление: используйте UTC. Нет оправдания.
Плохие смещения
Этот источник данных просто хочет быть немного другим, немного причудливым. Вместо предсказуемых 5-минутных интервалов он (почти) всегда опережает всего на несколько секунд. Это кажется злобным — они потрудились нормализовать свои данные в обычные 5-минутные сегменты, но просто не могут заставить себя сделать это так просто для нас.
Исправление: просто не делайте этого. Зачем тебе это?
Хаос
Ниже приводится без комментариев:
Исправление. Компьютеры были ошибкой, вернемся к солнечным часам.
