Установите TZ в соответствии с / etc / localtime

Для ASCII версии

groff -Tascii -mm PROMO.mm

Для postcript версии

groff -Tps -mm PROMO.mm
3
25.08.2016, 14:44
2 ответа

США / Тихоокеанский регион Чт 25 августа 02:12 равно Европа / Берлин Чт 25 августа 11:12 , так как время в Берлине на 9 часов опережает время Тихого океана в США

$ TZ=US/Pacific date -d 'Thu Aug 25 02:12' +%s
1472116320
$ TZ=Europe/Berlin date -d 'Thu Aug 25 11:12' +%s
1472116320

См. Смещения UTC:

$ TZ=Europe/Berlin date +%z
+0200
$ TZ=US/Pacific date +%z
-0700

Итак, ваш второй пример работает . Это третий, который не работает .

TZ = DE недопустимо в качестве стандартного определения зоны ( XXX [смещение] [YYY [dstoffset]] ), так как в нем всего 2 буквы и, вероятно, нет файла с именем DE в / usr / share / zoneinfo, поэтому по умолчанию используется время UTC.

$ TZ=DE date +%z
+0000

Если вы загрузили свою систему в 9:12 по берлинскому времени, то есть в 1472109120 по unix-времени, это будет означать, что ваши часы были выключены на два часа в то время, когда эта запись была добавлена ​​в wtmp .

Это одно из первых действий init при запуске системы. Обычно это происходит до запуска служб синхронизации времени в сети (которые исправляют эти часы). Другие ваши правильные записи wtmp предполагают, что часы были установлены на момент входа в систему первым человеком.

Если ваша система является мультизагрузочной и одна из других систем произведена Microsoft, обратите внимание, что системы Microsoft есть ошибка / несоответствие в том, что они по умолчанию устанавливают аппаратные часы на местное время, а не на всемирное координированное время. Итак, если ваша Unix-подобная ОС ожидает, что аппаратные часы будут в формате UTC, возникнет конфликт, когда вы загрузитесь в ОС Microsoft, ОС попытается перевести аппаратные часы с UTC на местное время, а ваша ОС Unix сделаю наоборот.

Согласно там , кажется, что больше невозможно исправить ОС Microsoft, поэтому вам нужно будет обойти это, сообщив вашей ОС Unix, что установлены аппаратные часы. на местное время, как в Windows (и убедитесь, что все операционные системы согласны с тем, что означает местное время) (и убедитесь, что вы не завершаете работу или не перезагружаетесь во время / во время перехода на летнее время). Например, в текущих системах Debian для этого нужно изменить UTC на LOCAL в / etc / adjtime .

Теперь, поскольку ваше adjtime уже содержит LOCAL , это исключает эту гипотезу. Другие возможности: у вас есть другая система, которая устанавливает часы на UTC, или это система Microsoft, в которой местное время установлено на UTC. Изменение LOCAL на UTC , вероятно, решит проблему.

Или, в более общем плане, вы хотите, чтобы все операционные системы в системе согласовали, какие аппаратные часы будут установлены.

3
27.01.2020, 21:15

Ваши аппаратные часы работают по местному времени, а не по всемирному координированному времени, поэтому временные метки загрузки сохраняются неправильно. (На это указывает запись LOCAL в / etc / adjtime .) last не регулируется для этого, поэтому отображаемое время загрузки сдвигается на разница между вашим часовым поясом и UTC (в настоящее время для Берлина два часа). Я не думаю, что есть какой-либо способ исправить это, кроме перехода на UTC для ваших аппаратных часов!

Остальная часть этого ответа не имеет отношения к вашей реальной проблеме, но по-прежнему актуальна при рассмотрении TZ и / etc / localtime .

Вообще говоря, чтобы использовать значение на основе файла в TZ , вы должны префикс имени файла с помощью : (подробности см. В tzset (3) ) :

TZ=:Europe/Berlin last reboot|head

Это будет работать с любым именем файла, используемым в качестве ссылки из / etc / localtime . При необходимости TZDIR можно использовать для переопределения местоположения по умолчанию ( / usr / share / zoneinfo ).

(Предполагается, что вы используете Linux с glibc ; : зависит от реализации, поскольку определен POSIX . В Linux вы обычно можете получить автор: без : , потому что обе формы TZ были предприняты.)

2
27.01.2020, 21:15

Теги

Похожие вопросы