UTC против localtime имеет смещение около 25 секунд

Я сравнивал это в разных системах, но получаю такое поведение во встроенной системе, на которой работает Arago linux. Я использую команду date из BusyBox v.1.13.2

Я выполнил две команды одновременно:

[root@host:~] date; date -u Fri Mar 18 12:56:49 CET 2016 Fri Mar 18 11:57:14 UTC 2016 

Выходной сигнал zdump соответствует ожидаемому (+3600 секунд, +1 час):

 /etc/localtime Sun Mar 29 01:00:24 2015 UT = Sun Mar 29 01:59:59 2015 CET isdst=0 gmtoff=3600 /etc/localtime Sun Mar 29 01:00:25 2015 UT = Sun Mar 29 03:00:00 2015 CEST isdst=1 gmtoff=7200 /etc/localtime Sun Oct 25 01:00:24 2015 UT = Sun Oct 25 02:59:59 2015 CEST isdst=1 gmtoff=7200 /etc/localtime Sun Oct 25 01:00:25 2015 UT = Sun Oct 25 02:00:00 2015 CET isdst=0 gmtoff=3600 /etc/localtime Sun Mar 27 01:00:24 2016 UT = Sun Mar 27 01:59:59 2016 CET isdst=0 gmtoff=3600 /etc/localtime Sun Mar 27 01:00:25 2016 UT = Sun Mar 27 03:00:00 2016 CEST isdst=1 gmtoff=7200 /etc/localtime Sun Oct 30 01:00:24 2016 UT = Sun Oct 30 02:59:59 2016 CEST isdst=1 gmtoff=7200 /etc/localtime Sun Oct 30 01:00:25 2016 UT = Sun Oct 30 02:00:00 2016 CET isdst=0 gmtoff=3600 /etc/localtime Sun Mar 26 01:00:24 2017 UT = Sun Mar 26 01:59:59 2017 CET isdst=0 gmtoff=3600 /etc/localtime Sun Mar 26 01:00:25 2017 UT = Sun Mar 26 03:00:00 2017 CEST isdst=1 gmtoff=7200 

Откуда это смещение составляет 25 секунд?

  • Mplayer cronjob не работает
  • Использование «%» в crontab
  • Bash: date -d выбрасывает «недопустимую дату», когда дата параметризуется
  • Изменить формат даты на месте с помощью команды `sed`
  • Как отслеживать скачок второго изменения после того, как это произошло?
  • дата означает недопустимую дату
  • Я не могу установить дату и время в Debian на основе оружия!
  • Формат даты для переменной
  • 3 Solutions collect form web for “UTC против localtime имеет смещение около 25 секунд”

    Следуя принципу первой команды ( date ):

     open("/etc/localtime", O_RDONLY) 

    Он получает доступ к файлу часового пояса, указанному в / etc / localtime, который / usr / share / zoneinfo / europe / Zurich в моем случае. Так что все хорошо.

    Стрельба второй команды ( date -u ) дала мне подсказки, почему она не работает должным образом:

     open("/usr/share/zoneinfo/UTC0", O_RDONLY) 

    В каталоге zoneinfo не было такого файла, поэтому мне пришлось скопировать UTC в UTC0, и теперь все работает так, как ожидалось.

     date; date-u Fri Apr 26 09:52:44 CET 2016 Fri Apr 26 07:52:44 UTC 2016 

    25 секунд была разница между POSIX-совместимыми зонами tz и «правильными» зонами tz в интервале 2012-07-01 до 2015-07-01. Если tzdata является старым, и если часовой пояс по умолчанию для оболочки, выполняющей эту команду, представляет собой POSIX CET, а часовой пояс «-u» является «правильной» версией UTC, тогда «правый» код будет считать, что системные часы нарушены POSIX, фактически подсчитывая все секунды прыжка, поэтому «правильный» код вычитает эти 25 секунд как часть преобразования системных часов в гражданское время.

    Разница между 04:05:12 CET и 1457838339 по модулю 86400 является часовым поясом. Если вы получаете смещение в 27 секунд, это означает, что в вашем определении часового пояса что-то не так, и оно заканчивается указанием смещения на 27 секунд вместо предполагаемого (предположительно) 1 часа. Проверьте настройку часового пояса, начиная с переменной TZ . Arago Linux использует Glibc, который имеет несколько опций для указания часовых поясов, но обычно использует файлы часового пояса из стандартной базы данных часовых поясов (так что TZ должен быть CET или лучше что-то вроде Europe/Paris чтобы подчиняться местным правилам DST и следовать исторической эволюции, или TZ следует отменить использовать /etc/localtime ). Вы можете использовать zdump -v для получения описания часового пояса.

    Linux и Unix - лучшая ОС в мире.