Для ASCII версии
groff -Tascii -mm PROMO.mm
Для postcript версии
groff -Tps -mm PROMO.mm
США / Тихоокеанский регион Чт 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
, вероятно, решит проблему.
Или, в более общем плане, вы хотите, чтобы все операционные системы в системе согласовали, какие аппаратные часы будут установлены.
Ваши аппаратные часы работают по местному времени, а не по всемирному координированному времени, поэтому временные метки загрузки сохраняются неправильно. (На это указывает запись 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
были предприняты.)