On the 00:00 1st of March 2024, Kazakhstan changes the clocks to a single time zone UTC +5 for the whole country. It will affect two time zones: Asia/Almaty and Asia/Qostanay, which are in UTC +6 and need to be adjusted.
And the question may arise – what to do?
As this blog is more about Virtualization, one thing to mention: there are not many problems. Most hypervisors work in the UTC +0 time zone, and the time zone should be correct inside the Guest Virtual Machines.
Many people ask: Will the NTP server move my clock back for an hour? The answer is no. NTP servers work in the UTC +0. And on the 1st of March, they won’t move your clock backward.
In this article, we will look briefly at Linux systems and how to change the time.
Each Linux distro has a tzdata package, which maintains all the information about time zones’ past and future changes. tzdata package name consists of the release year and an added letter – a/b/c/etc, depending on releases. For RHEL-based systems, you may check on tzdata announces on this page.
The next example will be based on Rocky Linux, which is identical to the other RHEL-Like distros. However, the overall principle should be the same for the non-RHEL distributive as well.
Let’s look at the currently installed tzdata package:
[root@ns01 ~]# rpm -qa | grep tzdata
tzdata-2023d-1.el9.noarchThe law about changing time zones in Kazakhstan was passed at the beginning of 2024, and it’s fair to guess that tzdata-2023 doesn’t contain information about the future clock’s change. According to this release, we may see that in the next tzdata package, named 2024a, those changes will be added.
So, first, we need to do, is to update tzdata package in the Linux distro, when it is added to the repository.
[root@ns01 ~]# dnf update tzdata
Upgrading:
tzdata noarch 2024a-1.el9After the update, check the current time zone state:
[root@ns01 ~]# timedatectl
Local time: Thu 2024-02-15 17:04:35 +06
Universal time: Thu 2024-02-15 11:04:35 UTC
RTC time: Thu 2024-02-15 11:04:35
Time zone: Asia/Almaty (+06, +0600)
System clock synchronized: yes
NTP service: active
RTC in local TZ: noYou may see that the time zone Asia/Almaty, which I use in this system, is displaying +6, and at this moment nothing has changed. How can we be sure that our clocks will move back?
In the RHEL-like systems, current time zone settings are located in the /etc/localtime file, which is just a symlink to the zoneinfo file.
/etc/localtime -> ../usr/share/zoneinfo/Asia/AlmatyWe can read this file using zdump command:
[root@ns01 log]# zdump -v /etc/localtime
...
/etc/localtime Sat Oct 25 20:00:00 2003 UT = Sun Oct 26 02:00:00 2003 +06 isdst=0 gmtoff=21600
/etc/localtime Sat Mar 27 19:59:59 2004 UT = Sun Mar 28 01:59:59 2004 +06 isdst=0 gmtoff=21600
/etc/localtime Sat Mar 27 20:00:00 2004 UT = Sun Mar 28 03:00:00 2004 +07 isdst=1 gmtoff=25200
/etc/localtime Sat Oct 30 19:59:59 2004 UT = Sun Oct 31 02:59:59 2004 +07 isdst=1 gmtoff=25200
/etc/localtime Sat Oct 30 20:00:00 2004 UT = Sun Oct 31 02:00:00 2004 +06 isdst=0 gmtoff=21600
/etc/localtime Thu Feb 29 17:59:59 2024 UT = Thu Feb 29 23:59:59 2024 +06 isdst=0 gmtoff=21600
/etc/localtime Thu Feb 29 18:00:00 2024 UT = Thu Feb 29 23:00:00 2024 +05 isdst=0 gmtoff=18000This file contains all changes in Asia/Almaty time zone since 1924. Fantastic! Let’s look at the few records at the end of the file:
/etc/localtime Sat Oct 25 20:00:00 2003 UT = Sun Oct 26 02:00:00 2003 +06 isdst=0 gmtoff=21600
/etc/localtime Sat Mar 27 19:59:59 2004 UT = Sun Mar 28 01:59:59 2004 +06 isdst=0 gmtoff=21600
/etc/localtime Sat Mar 27 20:00:00 2004 UT = Sun Mar 28 03:00:00 2004 +07 isdst=1 gmtoff=25200
/etc/localtime Sat Oct 30 19:59:59 2004 UT = Sun Oct 31 02:59:59 2004 +07 isdst=1 gmtoff=25200It was 2004, and the Country used Daylight saving time (isdst=1). Asia/Almaty time zone was in the UTC +6 or UTC +7, depending on the part of the year.
After that, DST was canceled in the Country:
/etc/localtime Sat Oct 30 20:00:00 2004 UT = Sun Oct 31 02:00:00 2004 +06 isdst=0 gmtoff=21600And the time zone has changed to the UTC +6 permanently (yes-yes).
And now we’re in 2024 when we need to change the time zone to UTC +5:
/etc/localtime Thu Feb 29 17:59:59 2024 UT = Thu Feb 29 23:59:59 2024 +06 isdst=0 gmtoff=21600
/etc/localtime Thu Feb 29 18:00:00 2024 UT = Thu Feb 29 23:00:00 2024 +05 isdst=0 gmtoff=18000Two last records indicate that on Feb 29 17:59:59 2024 UT we are in UTC +6, but on Feb 29 18:00:00 2024 UT we are moving to UTC +5.
Based on this info, we can be sure that tzdata package is updated and aware of the time zone change in Kazakhstan.
Now, how it will work? Let’s set the current time for one hour before the change:
[root@ns01 ~]# date -s "29 FEB 2024 22:58:40"An hour of waiting:
[root@ns01 ~]# timedatectl
Local time: Thu 2024-02-29 23:58:22 +06
Universal time: Thu 2024-02-29 17:58:22 UTC
RTC time: Fri 2024-02-16 03:43:24
Time zone: Asia/Almaty (+06, +0600)
System clock synchronized: no
NTP service: active
RTC in local TZ: noA bit more:
[root@ns01 ~]# date
Thu Feb 29 23:59:59 +06 2024And here it is. You may see that system time now displays in UTC +5 and the clock moved back an hour:
[root@ns01 ~]# date
Thu Feb 29 23:00:00 +05 2024[root@ns01 ~]# timedatectl
Local time: Thu 2024-02-29 23:00:04 +05
Universal time: Thu 2024-02-29 18:00:04 UTC
RTC time: Fri 2024-02-16 03:45:15
Time zone: Asia/Almaty (+05, +0500)
System clock synchronized: no
NTP service: active
RTC in local TZ: noAs expected, the time zone changed to UTC +5, and the displayed time as well.
Caveats: not all the system services can handle this change in time zone on the fly. For example, you may see that logs in the /var/log/messages file are still written in +6 instead of +5. You may try to restart services, but sometimes the reboot is simpler.
Some applications or databases may depend on the local time and time zone, and maybe it’s better to stop the application for an hour, at 23:00 GMT +6, and start it at 23:01 GMT +5 to not see the records from the future.
Although tzdata package is updating for current Linux releases, it may not be updated for the old ones. For example, for RHEL 5, so there is the only solution is to change the time zone from Asia/Almaty to something UTC +5 like Asia/Aqtau.
