ну, вот был у нас на днях перевод часов..
типа все уже в курсе и матерятся, что на час раньше надо вставать….
хорошо, система приняла нормально изменения:
$ 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
мдааа.. глюкаем?
Последние комментарии
-
OlegL, 17 декабря 2023 года в 15:00 →
Перекличка
21
-
REDkiy, 8 июня 2023 года в 9:09 →
Как «замокать» файл для юниттеста в Python?
2
-
fhunter, 29 ноября 2022 года в 2:09 →
Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt?
6
-
Иванн, 9 апреля 2022 года в 8:31 →
Ассоциация РАСПО провела первое учредительное собрание
1
-
Kiri11.ADV1, 7 марта 2021 года в 12:01 →
Логи catalina.out в TomCat 9 в формате JSON
1
ecobeing.ru
Экология и вегетарианство на благо всем живым существам Планеты.
Аналогично.
Кстати, а откуда date знает, что три дня назад еще было зимнее время?
по описанию временной зоны.
внутренне, время у системы хранится в UTC.
а когда процесс спрашивает локальное время, смотрится его (процесса) $TZ или, если оно пустое, берётся системное.
и время выставляется соответственно..
а вот почему разницу оно для «3 дня назад» показало в 7 часов — вот это и есть глюк.
ps: как подобное получить во free — я что-то не нашёл. date там не понимает -d :(
То есть в описании временной зоны записано, что вот такого-то числа тут время переводится на час вперед? Почему же тогда оно само не переводится, а лишь после ntpdate? Или это у меня криво настроено?
там написано, в какое время сколько нужно прибавить к UTC, чтобы получилось локальное время.
а оно в системе вообще не переводится. оно хранится в UTC, где это попросту не имеет смысла.
возможно, попросту не настроено вообще использовать временную зону…