Переход на летнее время linux
Обновлено: 05.07.2024
Мы очень часто пользуемся временем в Linux, начиная от простой задачи узнать сколько сейчас времени, до более сложной - посмотреть логи или узнать когда произошло то или иное событие в системе. Все завязано на времени, поэтому очень важно, чтобы часы шли правильно.
Наша планета разделена на часовые пояса, это было сделано с одной простой целью, чтобы время в любой точке планеты соответствовало солнечному времени. Время между этими зонами отличается на час и всего таких поясов - 24, за эталон взято время по нулевому, Гринвичскому меридиану.
Поэтому в определенный момент время в разных участках планеты будет отличаться на час. В этой небольшой статье мы рассмотрим как изменить часовой пояс Linux, чтобы операционная система правильно работала со временем и могла правильно его синхронизировать через интернет.
Как работает время в Linux?
Операционная система Linux хранит и обрабатывает системное время в специальном Unix формате - количество секунд прошедших с полуночи первого января 1970 года. Эта дата считается началом эпохи Unix. И используется не ваше локальное время, а время по гринвичскому меридиану.
Для преобразования времени по Гринвичу в региональное время используется часовой пояс. Это преобразование выполняется для каждого пользователя. Это необходимо, чтобы каждый пользователь мог настроить для себя правильное по его временной зоне время. Такое поведение просто необходимо на серверах, когда на одной машине могут работать люди из разных частей мира.
Настройка часового пояса в linux
1. Ссылка /etc/localtime
Наиболее популярный и поддерживаемый в большинстве дистрибутивов способ установки часового пояса для всех пользователей - с помощью символической ссылки /etc/localtime на файл нужного часового пояса. Список доступных часовых поясов можно посмотреть командой:
Сначала создайте резервную копию текущего часового пояса:
cp /etc/localtime /etc/localtime.bak
Для создания символической ссылки используйте команду ln -sf. Файл зоны нужно выбрать из доступных в системе. Например, мой часовой пояс - Украина, Киев, для установки будет использоваться следующая команда:
ln -sf /usr/share/zoneinfo/Europe/Kiev /etc/locatime
Теперь можете проверить текущее системное время с помощью утилиты date:
Если у вас установлена утилита rdate можно синхронизировать время с сетью:
sudo rdate -s time-a.nist.gov
Осталось только синхронизировать ваши аппаратные часы с новыми настройками, для этого выполните команду:
Если нужно изменить часовой пояс только для определенной программы или скрипта, просто измените для нее переменную окружения TZ, например:
Эта настройка сохраняется только для текущего сеанса командной оболочки. Чтобы сменить часовой пояс linux для определенного пользователя тоже нужно использовать переменную среды TZ. Только ее нужно добавить в файл
/.environment. Этот файл читается по умолчанию при входе в систему, а значит переменная будет доступна всем программам:
Готово, теперь вы знаете как выполняется настройка часового пояса linux для определенного пользователя.
2. Настройка с помощью tzdata
Если вы не хотите использовать описанный выше способ, можно воспользоваться специальными утилитами. Вот только в разных дистрибутивах используются свои утилиты. Рассмотрим варианты для самых популярных дистрибутивов.
В Red Hat Linux:
В CentOS и Fedora:
В Slackware или FreeBSD:
В большинстве случаев вы увидите подобное диалоговое окно:
Здесь просто нужно выбрать нужный часовой пояс и нажать кнопку Enter. После этого для окончательного применения настроек нужно будет перезагрузить систему.
3. Настройка с помощью systemd
В systemd есть своя утилита для настройки даты и часового пояса. Чтобы узнать текущее состояние выполните:
Для просмотра всех доступных временных зон выполните такую команду:
А для установки нужного часового пояса используйте команду set-timezone, например, тот же Europe/Kiev:
sudo timedatectl set-timezone Europe/Kiev
4. Настройка часового пояса в GUI
В дистрибутиве Ubuntu и других, использующих Gnome, настройка часового пояса Linux может быть выполнена прямо в параметрах системы. Для этого выберите пункт Сведения о системе, затем Дата и время, выберите свое местоположение на карте, или наберите название для поиска в поле ввода:
В KDE аналогично можно установить часовой пояс в настройках системы. Запустите утилиту настроек, откройте пункт Локализация, перейдите в раздел Дата и время, а затем откройте вкладку Часовой пояс:
Остается выбрать часовой пояс в списке и нажать кнопку Применить. Здесь уже изменения должны проявиться моментально.
Выводы
Теперь вы знаете как выполняется установка часового пояса в linux и сможете настроить не только свой домашний компьютер но и сервер с множеством пользователей, которым нужен отдельный часовой пояс для правильного местного времени. Если у вас остались вопросы, спрашивайте в комментариях!
На завершение видео, в котором подробно рассказано, что такое часовые пояса и зачем они нужны:
Все, наверное, хоть раз слышали, что в России с 2011 года отменен переход с летнего время на зимнее. Чем же это грозит каждому из нас — и администраторам большого количества серверов в сложных системах, и обычным пользователям, имеющим один компьютер и мобильный телефон? Что случится в ночь с 29 на 30 октября 2011 — до которой осталось, кстати, всего 2 недели?
У Europe/Moscow было два разных часовых пояса: летнее декретное время MSD = UTC+4 и зимнее время MSK = UTC+3. Теперь у этой timezone станет всего один общий часовой пояс, именующийся MSK и равный UTC+4. Другие временные зоны, использующиеся на территории РФ, меняются аналогичным образом, но проводить эксперименты всегда проще всего на наиболее «официальной» — т.е. именно Europe/Moscow.
Иллюстрировать изменения лучше всего на UNIX timestamp — это количество секунд, прошедших с начала Эпохи, 1970-01-01 00:00:00 UTC. Это простое целое число и оно абсолютно никак не зависит ни от каких часовых поясов и изменяющихся местных законов.
| Что именно | Timestamp | Было | Стало |
|---|---|---|---|
| Начало Эпохи | 0 | Jan 1 03:00:00 MSK 1970 | Jan 1 03:00:00 MSK 1970 |
| Зима начала 2011 года | 1296000000 | Jan 26 03:00:00 MSK 2011 | Jan 26 03:00:00 MSK 2011 |
| Лето 2011 | 1310000000 | Jul 7 04:53:20 MSD 2011 | Jul 7 04:53:20 MSK 2011 |
| Зима конца 2011 года | 1325000000 | Dec 27 18:33:20 MSK 2011 | Dec 27 19:33:20 MSK 2011 |
| За секунду до возможного переключения | 1319929199 | Oct 30 02:59:59 MSD 2011 | Oct 30 02:59:59 MSK 2011 |
| Сразу после переключения | 1319929200 | Oct 30 02:00:00 MSK 2011 | Oct 30 03:00:00 MSK 2011 |
Итого, как мы видим, момент истины или такой новый маленький локальный Y2k наступает с 1319929199 секунды на 1319929200-ую — либо все ломается, либо нет.
Для подавляющего большинства операционных систем апстримом (т.е. общим сайтом, который первоначально собирает всю эту информацию) являлся испытывающий сейчас определенный копирайтные сложности проект TZ database, располагавшийся по адресу elsie.nci.nih.gov/pub
Новые версии этой БД выходили регулярно и имели четкую систему нумерации: первые 4 цифры — номер года, затем одна буква — номер версии внутри года.
В TZ database соответствующие изменения были внесены весьма оперативно: закон РФ опубликован 2011-06-06, а изменения были опубликованы в версии 2011h от 2011-06-15.
Таким образом, если коротко: если в вашей ОС используется пакет типа tzdata с любой версией, равной или старше 2011h (т.е. 2011i, 2011j и т.д.) — то все в порядке.
Сильно зависит от того, что за система работает со временем и насколько эта работа критична.
Например, если у вас нет систем, которые работают с timezone Europe/Moscow — например, у вас все-все-все работает по UTC — то остаток статьи можно с чистой совестью не читать.
- Логи — если они ведутся не по UTC
- Базы данных, учетные системы, органайзеры
- Биллинг, бухгалтерские системы
- Любые системы, работающие в потоковом режиме 24x7: мониторинг, видеонаблюдения и т.д.
- Системы, которые выполняют функцию часов и будильников — т.е. мобильные телефоны, десктопы, отображающие время и т.д.
Нет, не переведут: с ntp-сервера приходит именно UNIX timestamp, который описан выше, а все операции с временными зонами производит операционная система, уже зная локальную настройку. До тех пор, пока локальная настройка — неверная, получение времени с ntp-сервера будет, наоборот, создавать проблему, которую даже вручную толком не решить: придется либо отказываться от использовании ntp, либо попытке «подвести на час» через некоторое время ntp все «исправит» обратно. «Чинить» нужно именно timezone.
В общем, нет: именно UTC (Universal Time, Coordinated) используется как основной стандарт по всему миру со времен изобретения атомных часов (
начало 1960-х) — в технике, в авиации, в астрономии и во всех остальных местах, где нужно точное время.
Если совсем коротко — то GMT и UTC принципиально различаются по механизму учета времени — в GMT он куда более «неудобный» для техники. В разные моменты времени GMT и UTC могут отставать друг от друга до
0.9 секунды. Несмотря на то, что прошло уже порядка 50 лет, люди все равно по инерции часто произносят «по Гринвичу» и даже умудряются действительно регулярно писать аббревиатуру GMT.
Ниже я постарался собрать всю информацию о том, когда, где и что обновлялось и как можно быстро проверить, будет ли иметь проблемы та или иная система.
Универсальный способ проверки
Универсальный, но весьма длинный способ проверки — годится, в частности, для любых мобильных телефонов и прочих подобных устройств: выставить часы принудительно на 2011-10-30 01:59 и подождать 1 час и 1 минуту. Если устройство/ОС переставит после этого часы на 02:00 — то, значит, все плохо, timezone не обновлены. Если часы останутся на 03:00 — все в порядке, изменения применены.
Linux
Если он выдает что-то, отличное от OK и нулевого exit status — то проблема на тестируемой системе есть. Нужно попробовать обновить систему: если поможет, отписаться, что в таком-то дистрибутиве с такой-то версии такого-то пакета с timezones проблема исчезла; если не поможет — то отписаться, что в таком-то дистрибутиве проблема есть до сих пор.
FreeBSD
Исправления в head и в stable FreeBSD 8 были внесены 2011-06-28.
Как проверять: запустить чуть-чуть измененный вариант скрипта, приведенного выше:
Скорее всего этот же скрипт подойдет и для Mac OS X. Буду признателен, если кто-то расскажет, как там обстоят дела.
Solaris
- SPARC, Solaris 8: patch 109809-17
- SPARC, Solaris 9: patch 113225-29
- SPARC, Solaris 10: patch 146470-04
- x86, Solaris 8 patch 109810-17
- x86, Solaris 9 patch 116545-27
- x86, Solaris 10 patch 146471-04
Windows
- Windows 7
- Windows Server 2008 R2
- Windows Server 2008 SP2
- Windows Vista
- Windows Server 2003 SP2
- Windows XP SP3
Есть также ручное решение, описанное в 914387.
(подсказывает ComputerPers)
Гораздо более подробное описание решений для Windows-систем и подсистем на их базе можно прочитать в отдельной статье «Изменение часовых зон в России, Белоруссии, Украине и Армении» от roman_tik.
Язык Java, как правило, носит свои timezones с собой где-то в районе $JAVA_HOME/lib/zi — но в некоторых случаях (при инсталляции пакетом из дистрибутива) эти файлы генерируются на основе общесистемных.
В «официальной» поставке Oracle Java SE изменения внесены на основе 2011h, номер версии 1.3.40, обновление от 2011-06-29.
Как проверять: создать файл TestMSD.java с таким содержимым:
Android
Общая база данных для временных зон живет в Android-системе обычно в файле /etc/timezones.db , откуда ее использует java-машина и все приложения на java. Выделенной /usr/share/zoneinfo в системе по умолчанию нет.
- Asus TF101 — последняя штатная прошивка от ASUS, Android 3.2.1 — все плохо (проверил flashvoid)
- Google Nexus One — последняя официальная прошивка (2.3.6) — все плохо (проверил binba)
- Google Nexus One — c прошивкой CyanogenMod-7.1, build 220 от 2011-10-13 — все плохо (проверил Anjin)
- Google Nexus S — последняя официальная прошивка (2.3.6) — все плохо (проверил 8bitjoey)
- Google Nexus S — прошивка WhisperCore 0.5.5 — все плохо (проверял Darka)
- HTC Desire — последняя официальная прошивка (2.29.405.5 CL293415, Android 2.2) — все плохо
- HTC Desire — developer preview (2.3.3) — все плохо (проверил LanG)
- HTC Desire Z — последнее обновление (2.42.205.2, Android 2.3.3) — все плохо (проверил AlexeyRU)
- HTC Desire Z — с последней прошивкой MIUI (1.10.07) — все плохо (проверил NoOne)
- HTC Desire HD — последняя официальная прошивка (2.50.405.2, Andriod 2.3.3) — все плохо (проверил dolgonosic)
- HTC Legend — сборка 3.15.405.3 CL291292 (Android 2.2) — все плохо (проверил ihoru)
- HTC Wildfire S — с прошивкой 1.33.401.2, Android 2.3.3 — все плохо (проверил Wildy)
- LG Optimus One — с прошивкой LG-P500-v20C, Android 2.3.3 — все плохо (проверил ChemAli)
- LG Optimus One — с прошивкой LG-P500-v20D, Android 2.3.3 — все плохо (проверил Nikolaich)
- Motorola Milestone — последняя официальная прошивка (2.1-update1, Android 2.1) — все плохо
- Samsung Galaxy S II — прошивка на Android 2.3.3, все плохо (проверил aim)
- Samsung Galaxy Ace — последняя прошивка S5830XXKPO, Android 2.3.5 — все хорошо (проверил Bytamine)
Maemo
- Maemo5 (AKA Fremantle), Nokia N900 — все плохо
- Maemo6 (AKA MeeGo 1.2 Harmattan), Nokia N9/N950 — все в порядке
Symbian
- Symbian Anna, Nokia E7 — проблема есть (проверял wholeman)
Так как тема эта в целом весьма обширная, поэтому прошу помощи хабрасообщества в проверке всего, до чего можно дотянуться, чтобы создать своего рода справочник: что уже обновлено, что можно обновить (и в каких именно обновлениях этот патч накладывается), что ломается, а что нет — в частности, как с этим обстоят дела в тех системах и средах, где у меня не добрались руки проверить: различные версии Windows, Mac OS X / Classic, различные версии/прошивки Symbian, Android, iOS, MeeGo, Windows Mobile/Phone 7, Nabaztag, Playstation/XBox, Perl, PHP, Ruby, Python, SQL-базы и т.д.
Переход на летнее время (Не перевелись часы)
Любые разговоры которые хоть как-то связаны с тематикой форумаquest Предупреждения: 0
Переход на летнее время
подумал -> выпил -> подумал -> . но недавно врачи запретили пить.2 quest
Настрой localtime, а ещё лучше - юзай ntpdate
quest Предупреждения: 0 У меня одного, что-ли, не перевелось?Потом в Панели управленя KDE - системное администрирование - дата и время обнаружил, что у меня не был выбран регион. Но ведь при установке Слаки я указал, что мой часовой пояс - Москва, почему же это в КДЕ не установилось?
И вообще, во сколько время должно было перевестись?
Про ntpdate я знаю, но хочу разобраться, почему мой Линь сам не перешел на летнее время. Хы.. у меня пока комп был разобран системное время было 2000-го года Пришел домой собрал, в биосе только год потерял. Загрузился линух сказал, что система не запускалась пару тысяч дней, сделал проверку, потом загрузился, потом я спокойно выполнил ntpdate. Вот результат:
А у меня лажа получилась.
Как раз во время перевода в винде был (так было надо)
И не смог проверить
Кстати, у меня комп за сутки нагоняет минуту-две, каждый день приходится обновлять через ntpdate. Это батарейка? (полтора года уже работает)
Блин, перевелось-то оно перевелось, но вставать на час раньше - это САКССумасшедший юниксоид в синей футболке с рыбой(с)
Ошибки юности легко сходили с pyк
Ах, молодость, - волшебный звyк свиpели.
Мы часто под собой пилили сyк.
Тепеpь и мы не те, и сyки постаpели.
2 Sten
Привыкнешь, не ты один такой.
А что, держать в BIOS время в UTC и нормально настраивать timezone уже не модно? Читаю вслух с выражением маны - $50/ч + стоимость звонка. Настраиваю сервисы за Вас - $100/ч + стоимость выезда и проживания.И восемь строк матом. (бесплатно) quest Предупреждения: 0 Кстати, на форуме время тоже не перевелось.
Хостимся где? На хоботе? Раньше было время московское, теперь - MSK-1 :P Для clx:
Вроде, среда уже, а до сих пор не привык.. И привыкну, видимо, не раньше, чем отосплюсь в выходные..
Сумасшедший юниксоид в синей футболке с рыбой(с)
Ошибки юности легко сходили с pyк
Ах, молодость, - волшебный звyк свиpели.
Мы часто под собой пилили сyк.
Тепеpь и мы не те, и сyки постаpели.
Если дохнет батарейка, то часы вообще каждый раз вместе со всем остальным CMOS'ом слетают
Это у тебя генератор на материнке какой-то косячный.
Синхронизируйся чаще (Strangerrr @ Понедельник, 28 Марта 2005, 7:30) писал(а): А что, держать в BIOS время в UTC и нормально настраивать timezone уже не модно?
Плюс ntpd при постоянном соединении и ntpdate при модемном.
А вообще идея с летним/зимним временем - такой же бред, как лепнинское декретное время. Разговоры о экономии энергии - чушь по вполне понятным причинам. Единственное разумное объяснение этому предложил Виктор Суворов в романе "Выбор" устами Насти Стрелецкой: нужно заставить людей делать бессмысленные вещи. Например, два раза в год переводить часы туда/сюда.
(Strangerrr @ Понедельник, 28 Марта 2005, 7:30) писал(а): А что, держать в BIOS время в UTC и нормально настраивать timezone уже не модно? Беда в том, что никто мне так вразумительно и не ответил, как заставить винду понимать UTC..(alv @ Воскресенье, 03 Апреля 2005, 8:53) писал(а): А вообще идея с летним/зимним временем - такой же бред, как лепнинское декретное время. Разговоры о экономии энергии - чушь по вполне понятным причинам. Единственное разумное объяснение этому предложил Виктор Суворов в романе "Выбор" устами Насти Стрелецкой: нужно заставить людей делать бессмысленные вещи. Например, два раза в год переводить часы туда/сюда. Это да. Понится, как-то (кажется, как раз после отмены декретного часа) жили мы пару годков без летнего времени -- а потом за каким-то фигом возобновили.. (Lin @ Среда, 30 Марта 2005, 20:16) писал(а): Если дохнет батарейка, то часы вообще каждый раз вместе со всем остальным CMOS'ом слетают
Это у тебя генератор на материнке какой-то косячный.
Синхронизируйся чаще
а сколько, кстати, положено средней батарейке жизни? года три - норма, или больше? (Juliette @ Воскресенье, 03 Апреля 2005, 14:38) писал(а): а сколько, кстати, положено средней батарейке жизни? года три - норма, или больше?
Вспоминаю свои служебные машины 97-98 года розлива. Живы батарейки
Нууу. у тогдашних машин всё живо до сих пор. А я блок питания недавно после всего 3-х лет работы недавно поменяла. CHINA forewer!а всё-таки, если блоковый бипер иногда сипло пищщыт и время прыгает - это батарейка, да? (Juliette @ Воскресенье, 03 Апреля 2005, 15:20) писал(а): Нууу. у тогдашних машин всё живо до сих пор. А я блок питания недавно после всего 3-х лет работы недавно поменяла. CHINA forewer!
а всё-таки, если блоковый бипер иногда сипло пищщыт и время прыгает - это батарейка, да?
С бипером - не знаю. А время может прыгать по тысяче разных причин (некоторые тут уже перечисляли). Однозначный показатель смерти батарейки - если после перезагрузки время становится на ноль часов 1 января 1980 года (или там аналогичного).
Мама чья? По моему опыту на мамах класса ASUS/Gigabyte (не говоря уж о Tyan/Supermicro) о жизни батарейки можно не думать (ЛЮДИ столько не живут). На помидорном классе - и за год могут сдохнуть. А вот о промежуточном у меня данных очень мало
Я пытался найти способ получать уведомление от системы (Linux) о переходе на летнее время, но, похоже, не могу найти ничего подобного.
Представьте, что программа сидит на pselect() в ожидании определенного количества таймеров fd , каждый из которых имеет ровно 24-часовые интервалы, но разное время запуска, которое определяется пользователем; " 07:00 ON , 07:25 OFF " (например, если бы это была кофеварка).
Поскольку пользователь указывает это время по местному времени, а Linux работает по всемирному координированному времени, таймер fd с корректировкой часового пояса необходимо заново настраивать каждый раз, когда происходит переход на летнее время. (пользователь ожидает кофе, когда его будильник, соответствующий летнему времени, разбудил его . )
Как я могу себе представить, разумный способ сделать это - зарегистрироваться в системе / ядре / инициализации / что угодно, чтобы получать уведомления о переходе на летнее время, и не вмешиваться в грязный бизнес, пытаясь самостоятельно определить такие даты и время. и надеюсь, что система согласится с вашими результатами (т.е. ваши действия по повторной синхронизации и фактический переход на летнее время происходят в одно и то же время).
Есть ли способ получать уведомления об изменении летнего времени? Или, возможно, при любых изменениях местного времени (при условии, что изменение летнего времени меняет это)?
2 ответа
Представьте, что программа сидит на pselect () в ожидании нескольких fd таймера, все из которых имеют ровно 24-часовые интервалы, но различаются по времени запуска.
В этом ваша основная проблема. Не все дни длятся ровно 24 часа - иногда они отличаются на час (летнее время) или на секунды (дополнительные секунды); как и не в каждом феврале 28 дней.
Гораздо более простой и легкий (с меньшим потреблением ресурсов) способ - использовать минимальную кучу будущих событий в UTC, что-то вроде
Элемент гибкого массива event C99 в struct event_min_heap - это массив с событиями num_events (память, выделенная для max_events ; может быть перераспределена, если требуется больше событий) в min heap с ключом поля when в каждой записи event . То есть самое раннее событие всегда находится в корне.
Всякий раз, когда текущее время составляет не менее event[0].when , оно «запускается» - это означает, что любое действие, которое должно быть предпринято, выполняется - и на основе struct trigger , к которому оно относится, время следующего появление этого события обновляется до event[0] , затем оно проникает в кучу в нужное место. Обратите внимание, что вы просто используете mktime() для получения Время UTC из разбитых полей местного времени.
(Если это была многопользовательская служба, то вы можете поддерживать несколько одновременных часовых поясов, по одному для каждого триггера, установив для переменной среды TZ соответствующее определение часового пояса и вызвав tzset() перед вызовом mktime() . Поскольку среда является общей для всех потоков в процессе, вам нужно будет гарантировать, что только один поток делает это за раз, если у вас многопоточный процесс. Обычно такие вещи вполне можно реализовать с помощью одного -зарезной процесс.)
Когда событие в корне ( event[0] ) удаляется или просеивается (просеивается), событие со следующим наименьшим значением when будет в корне. Если when равно или меньше текущего времени в UTC, оно также запускается.
Когда следующий when наступает в будущем, процесс может "засыпать" оставшийся интервал.
Вот и все. Вам не нужны несколько таймеров - которые являются ограниченным ресурсом всей системы - и вам не нужно беспокоиться о том, является ли какое-то местное время летним или нет; библиотека C mktime() позаботится об этом за вас.
Крайне важно понимать, что mktime() вычисляет Время Unix Epoch ( time_t ) для указанного момента, применение летнего времени, если оно применяется в этот конкретный момент . При вызове функции не имеет значения, действует ли летнее время!
Кроме того, время UTC - это всемирное координированное время и не зависит от часовых поясов или перехода на летнее время.
Рассмотрим следующую программу, mktime-example.c :
Скомпилируйте его, например,
Запустите его без аргументов, чтобы увидеть использование командной строки. Бежать
Изучить временные метки Unix примерно в то время, когда в 2016 году заканчивается летнее время в Хельсинки, Финляндия. Команда выведет
Результат будет одинаковым независимо от того, действует ли во время запуска это летнее время в каком-либо часовом поясе или нет!
При вызове mktime() с помощью .tm_isdst = 0 или .tm_isdst = 1 и mktime() его изменения, он также изменяет указанное время (на летнее время). Когда .tm_isdst = -1 , это означает, что вызывающий абонент не знает, применяется ли летнее время или нет, и библиотека узнает; но если есть и действительное стандартное время, и время DST, библиотека C выберет одно (вы должны предположить, что это происходит случайно). Вышеупомянутая функция epoch() исправляет это, когда это необходимо, отменяя настройку времени, если пользователь неверно указал летнее время.
Системы Unix / linux работают только с UTC, и они используют данные time_t (количество секунд с 00:00 января, 1 января 1970 года по всемирному координированному времени до настоящего времени) в качестве внутреннего времени. Преобразование в местное время (со сложностями из-за исключений, вариаций для летне-зимних периодов и т. Д.) Выполняется только при отображении информации пользователю, поэтому только при преобразовании в местное время. Как уже было сказано, в системе unix нет никаких условий для планирования чего-либо или подготовки к этому.
Из zdump(1) вы можете получить всю необходимую информацию для каждого часового пояса и использовать ее для создания crontab, чтобы уведомить вас, когда должно быть выполнено переключение. Он обращается к локальной базе данных часовых поясов и извлекает всю информацию о переключении (включая исторические) с зимы на лето или наоборот.
Кстати, если вы хотите получить уведомление о неизбежном изменении местного времени, вы можете использовать предыдущую информацию для создания файла crontab, включая всю информацию, или просто создать файл crontab, который включает правила, применяемые в вашем регионе. Например, если я хочу, чтобы меня уведомили за день до смены коммутатора в Испании (оно меняется в последнее воскресенье марта / октября, в 02/03 часа), вы можете добавить несколько правил в свой файл crontab:
И письмо будет отправлено вам каждую субботу (5), которая приходится на неделю с 24-30 марта и октября (3,10 часть) каждого года в 00:00 (по местному времени). Я уверен, что вы сможете адаптировать этот пример к вашей местности или времени заранее (то есть за день до того, как произойдет изменение времени).
Читайте также: