"я не знаю, был ли я все еще воскресным или уже понедельничным"

Update: первое место на конкурсе известно кого занимает PHP, где таблица таймзон - вшитая, а не системная. Всех бы убил, да. pecl-timezonedb спасает.

Приз зрительских симпатий за перевод часов получает Яндекс-почта.

Рассказываю:

  • На часах 11:26 (правильного времени), вхожу в Я-почту, вижу там внизу "последний вход в 10:54"
  • Действительно, в 10:54 я туда заходил, написать сам себе письмо и посмотреть на даты в заголовках (и все было прилично).
  • Выхожу (на часах 11:26), вхожу, выхожу, вхожу.
  • Надпись внизу остается все та же, про 10:54.
  • Повторяю еще и еще раз, наконец в 11:55 добиваюсь, надпись меняется на 11:26 (время начала экспериментов). Хотя с 11:26 я входил и выходил раз 10 минимум (а в промежутке 10:54-11:26 - нет).
  • Подозреваю, что в следующий раз "время последнего входа" сменится в 12:26 MSK, через полчасика проверю. Yes! Теперь оно залипло на 11:56

Я, естественно, не знаю в чем там причина, но предполагаю что

  • На части серверов время таки перевелось (часть - честно ставит правильный заголовок Date в почте, да и на глагне у Яндекса более-менее все в порядке)
  • В процессе работы Яндекс-Почты возникает передача (или разбор, или хранение) локального времени без учета таймзоны.

    Или, хитрее (и хуже): таймзона передается и анализируется, но в виде буковок MSK/MSD. А MSK у нас раньше была +0300, а стала +0400.

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

Второе место у телефона на WinMobile 6 (или 6.5, не вдавался), сообщение: произведен переход на летнее время.

А мораль в той басне понятно какая (это я не Яндексу, там сами разберутся, ибо умные):

  • Или хранить, передавать и т.п. все в UTC, а только визуализацию делать в локальном времени.
  • Или, в крайнем случае, в формате HH:MM:SS +OFST, но тогда честно разбирать смещение.
  • Но никаких HH:MM:SS (локальных) или HH:MM:SS TZNAME, потому что смысл TZNAME имеет свойство меняться, а разбирать время по полной истории всех таймзон - это же удавиться.

Comments

А вот например, у этого поста наверху написано

Это по какому времени? Точно не по моему, у меня сейчас 8:20.

У меня тоже не 11, а в заголовке наблюдаю 11:10:00 :)

Я так понимаю, жежешечка показывает в этом месте локальное время автора поста. А в комментариях то ли локальное время читателя, то ли UTC. Различить не могу, у меня локальное время как раз UTC и есть. Например, у первого комментария к этому посту я вижу время "08:22 am UTC"

Я тоже для каментов вижу UTC. Вероятно, это как-то настраивается для каждого юзера отдельно (должно влиять на показ), но я даже не знаю где посмотреть

О, нашел. Это в Edit Profile - viewing options, там списком.

Поставил Europe/Moscow, оно оказалось +0300
Кто бы сомневался.

Ага, это подарок от PHP, похоже. Изучу, да.

Он, родимый. См. апдейт.

Убил бы нахер.

Это, в смысле, твой блог при кросспостинге в ЖЖ явно указал время публикации, сдвинутое на час?
А внутри он его как хранит - в UTC или в твоём локальном времени? Показывает-то он его правильно: "ВС, 10/30/2011 - 12:10"

Хранится все в UTC (тип timestamp в постгресе, что было бы у тех, кто на MySQL - я даже думать не хочу).

Как передается - я не вдавался, но вероятно с таймзоной "блога". А ЖЖ показывает что передано, но без таймзоны.

А дальше два подарка сразу
1) PHP-шные таймзоны устарели, я их поапдейтил.
2) у Друпала есть галка "пользователи могут быть со своей таймзоной", она была включена. А в *этом месте* таймзона хранится в секундах от UTC. Гы.

Timestamp with time zone? По умолчанию он without.

without, но это похрен, ибо оба timestamp - в UTC.

(ворча) когда уже везде повсеместно введут UTC
Уж на серверах то точно надо.

А жизнь то у нас - не по UTC.

Всякие суточные статистики, биллинги, времена написания сообщений и так далее. Что там у сервера в ядре - без разницы, а всякая внешняя жизнь привязана к тем часам, что на спасской башне.

Так может часы на сасской тоже пора на utc переставить? ;)

Ирландия плачет по таким!

У нас тут в ЛТ разное вермя абсолютно со всеми соседями (и в Калининграде тоже). А еще мне хочется единения по таймзоне с заказчиками и их серверами.

PS Пользуясь случаем -- хочу передать привет хостерам которые в клиентские VE радостно выставляют Europe/Moscow не смотря на сервера в штатах, и клиентов непойми где)

а что мешает в клиентских VE поменять TZ и файлы TZ самостоятельно?
хостеры не подписываются управлять потрохами VE, как правило.

Проблема с виртуальными машинами в том, что они плодятся как кролики.

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

А jail-ов, виртуальных машин и т.п. - десятка полтора. И, по хорошему, каждую надо бы проверить на предмет.

именно поэтому у меня в стандартах конфигурации прописано, что если нет причин настраивать иначе - на сервере/виртуалке TZ==UTC

Может быть.

Но как только на виртуалки лезут реальные сервисы, так сразу хочется, чтобы там время в логах было человеческое. И кронтабы можно было бы писать без поправки прицела.

мне как раз проще UTC
чтобы не думать, в какой части света этот сервер и для кого он работает :)

Ну если всякой внешней синхронизации, вроде детей в школу, нету, то IT-шнику от Калининграда до Барнаула или даже Кызыла можно вполне естественно жить по UTC. Даже солнце иногда видеть будет.

Или хранить, передавать и т.п. все в UTC, а только визуализацию делать в локальном времени.
Или я торможу, или это всё равно требует хранения полной истории всех тайм-зон. Чтобы визуализацию делать правильно.
Так что от HH:MM:SS TZNAME этот подход отличается только моментом/частотой разбора истории таймзон.

Главная жопа - это *разбор* TZNAME (а не +OFST).
Вот MSK - до 27 марта сего года была +0300, MSD - +0400. А с марта - MSK +0400, а MSD и вовсе нет. Ну или не с марта, а с 31 октября, тут мнения могут разойтись.

А в каком количестве мелких софтин вбиты константы +0300/+0400 - я и подумать боюсь. Припоминаю, что и сам так мог что-то (не помню что) спрограммировать лет 15 назад.

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

вспомнил, кстати, забавный ежегодный гимор с переводом времени: осенью "размазывать" "лишний" час по статистике суток, а весной, наоборот, замазывать от оставшейся части суток, чтобы не возбуждались клиенты и различные мониторинги :)

Add new comment