NEW BOT Телеграм, страница

Forwarded from Стой под стрелой (Nikita Prokopov)

Работа со временем, часть 3/3

Тут уже будет про всякие курьезы. Во-первых, сильно не завидую составителям tz database, потому что им приходится иметь дело со сложностью человеческого мира и неточностью «обыденных» определений. Скажем, были города, в которых половина жила по одному времени, а половина — по другому. Какие-то города, например, Берлин, находились вообще в двух странах.

Другая штука — путешествие в прошлое. Как вы видели, Unix timestamp начинается с 1970-го, но можно ли продолжить его в прошлое? Немножко можно, насколько позволяет tz database, но там уже начинается неполнота данных о часовых поясах и прочий разброд. Если совсем сильно продолжать, то начинаются вопросы, скажем, переход между Юлианским календарем и Грегорианским был довольно долгим и хаотичным географически и зафиксирован не очень точно.

Сколько дней в феврале? 28-29, да? Часов в сутках? 23-25, как мы определили выше. А вот сколько секунд в часе? 3600, да? Не всегда 🙂 Про високосный год все знают, а как вам високосная секунда?

Но давайте по порядку. В 1972 запустили атомные часы, которые без остановки и прочего булшита отсчитывали по одной секунде каждую секунду 🙂 Их время называется International Atomic Time (TAI) и является, наверное, самой базовой величиной которая у нас есть (да, я говорил, что unix timestamp, но нет). С момента запуска они обогнали UTC на 37 секунд.

Далее есть UT1. Это время, основанное на вращении Земли, в предположении, что каждый новый год наступает ровно в 00:00:00 по UT1. Но! Штука в том, что вращение Земли, во-первых, замедляется, а во-вторых неравномерно и непредсказуемо (!! да, блин! Потому что по ней всякий хлам типа морей, магмы и материков болтается) и в итоге каждый год (по астрономическим наблюдениям вращения Земли) имеет слегка разную продолжительность в секундах.

UTC это компромисс для удобства обычных людей: это тот же TAI (т.е. атомные стабильные секунды), к которому иногда добавляют или отнимают по одной секунде в год, чтобы Новый год наступал как можно ближе к 00:00:00 по UT1 (астономическому).

Пока секунды только добавляли, обычно это делают как 23:59:60 31 декабря или 30 июня. Это происходит нерегулярно, основано на астрономических измерениях и никто заранее не может сказать, когда и сколько их в будущем будет добавлено. Последнюю добавляли в 2016-м.

Как это все переносится на Unix time? А никак 🙂 В Unix time такое понятие не заложено. Если число делится на 3600000, значит это граница часа. Удобно — но также и слегка неправда.

Что же делают компьютеры? Вариантов немного — можно либо повторить 23:59:59 два раза (перевести на секунду назад), либо заморозить часы, либо размазывать эту секунду тонким слоем на целые сутки (вроде Гугл этим хвастался, но не подскажу где).

Именно поэтому Unix time это очень удобная точка отсчета в практическом смысле, но немножко неправда до самого конца. Но на деле — скорее всего, о високосной секунде вам париться не придется. Правда в JVM был какой-то баг на эту тему (скорее всего, что-то про немонотонность часов), и я лично вроде как в 2012-м что-то там из-за этого у нас перезапускал.

Но это слишком редко, чтобы на самом деле имело смысл париться. А немонотонность часов — ну, из-за синхронизации времени они точно так же могут скакнуть назад, так что доверять нельзя никому.

Такие дела. Практически про работу со временем — как только понимашь, что происходит, сразу перестает быть сложно. Надеюсь, гайд вам чем-то поможет. Распространяйте, это может спасти чью-нибудь жизнь 🙂

👍1

87 views07:54