nixp.ru v3.0

23 октября 2017,
понедельник,
01:59:03 MSK

DevOps с компанией «Флант»
Genie написал 27 марта 2006 года в 11:36 (292 просмотра) Ведет себя как мужчина; открыл 40 тем в форуме, оставил 4758 комментариев на сайте.

ну, вот был у нас на днях перевод часов..

типа все уже в курсе и матерятся, что на час раньше надо вставать….

хорошо, система приняла нормально изменения:

$ date; date -u
Пнд Мар 27 14:33:38 NOVST 2006
Пнд Мар 27 07:33:38 UTC 2006

а как же оно было-то до этого, в тяпницу-то? узнаём:

$ date -d "3 days ago"; date -ud "3 days ago"
Птн Мар 24 14:36:04 NOVT 2006
Птн Мар 24 07:36:04 UTC 2006

мдааа.. глюкаем?

Feuerbach

Аналогично.

Кстати, а откуда date знает, что три дня назад еще было зимнее время?

Genie
Кстати, а откуда date знает, что три дня назад еще было зимнее время?

по описанию временной зоны.

внутренне, время у системы хранится в UTC.

а когда процесс спрашивает локальное время, смотрится его (процесса) $TZ или, если оно пустое, берётся системное.

и время выставляется соответственно..

а вот почему разницу оно для «3 дня назад» показало в 7 часов — вот это и есть глюк.

ps: как подобное получить во free — я что-то не нашёл. date там не понимает -d :(

Feuerbach
Genie
по описанию временной зоны.

То есть в описании временной зоны записано, что вот такого-то числа тут время переводится на час вперед? Почему же тогда оно само не переводится, а лишь после ntpdate? Или это у меня криво настроено?

Genie
То есть в описании временной зоны записано, что вот такого-то числа тут время переводится на час вперед?

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

Почему же тогда оно само не переводится

а оно в системе вообще не переводится. оно хранится в UTC, где это попросту не имеет смысла.

а лишь после ntpdate? Или это у меня криво настроено?

возможно, попросту не настроено вообще использовать временную зону…