The past year—particularly the second half of 2021—was a busy one for the Time Zone Database (tzdata) project, which provides Red Hat Enterprise Linux (RHEL) with data specific to the local time zone. Project contributors engaged in lively discussion over how to treat historical time zone data, and changes in some countries' daylight saving time (DST) start and end dates—including one announced with less than two weeks' notice—kept the maintainers busy.
The tzdata package contains the data files documenting both current and historic transitions for various time zones around the world. This data represents changes required by local government bodies or by time zone boundary changes, as well as changes to UTC offsets and DST. The GNU C Library (glibc) uses the tzdata package in order to make APIs such as strftime() work correctly, while applications such as /usr/bin/date make use of this information to print the local date.
2021 began slowly with the January release of the update tzdata 2021a, which supported time zone changes in South Sudan. However, over the subsequent months, significant changes were introduced upstream that combined or merged time zones and resulted in a lot of controversy.
Merging time zones
When the upstream project proposed merging time zones, a lengthy and often heated discussion began and continued over the next several months. The dispute involved the upstream project's decision to merge time zones whose timestamps and DST transitions were alike since 1970, a process now known as the alike-since-1970 changes.
The decision on which time zones would be merged or replaced was based on the populations of the represented areas. The name of the original time zone with the larger population was used for the newly merged zone. The related discussions included debates about inclusion and historical accuracy, as well as other concerns.
America/Creston and America/Phoenix offer an example of the historical issues raised by this process. The two zones have had the same timestamps and DST transitions since 1970. However, the pre-1970 timestamps and DST transitions were often different.
Merging the time zones resulted in what had been America/Creston becoming part of America/Phoenix. This means that the pre-1970 data for America/Creston has been replaced with the pre-1970 data for America/Phoenix, as you can see from the following output from zdump commands. Here's the output using the version of the database updated to tzdata-2021a:
# zdump -v America/Creston
America/Creston -9223372036854775808 = NULL
America/Creston -9223372036854689408 = NULL
America/Creston Tue Jan 1 07:46:03 1884 UT = Mon Dec 31 23:59:59 1883 LMT isdst=0 gmtoff=-27964
America/Creston Tue Jan 1 07:46:04 1884 UT = Tue Jan 1 00:46:04 1884 MST isdst=0 gmtoff=-25200
America/Creston Sun Oct 1 06:59:59 1916 UT = Sat Sep 30 23:59:59 1916 MST isdst=0 gmtoff=-25200
America/Creston Sun Oct 1 07:00:00 1916 UT = Sat Sep 30 23:00:00 1916 PST isdst=0 gmtoff=-28800
America/Creston Sun Jun 2 07:59:59 1918 UT = Sat Jun 1 23:59:59 1918 PST isdst=0 gmtoff=-28800
America/Creston Sun Jun 2 08:00:00 1918 UT = Sun Jun 2 01:00:00 1918 MST isdst=0 gmtoff=-25200
America/Creston 9223372036854689407 = NULL
America/Creston 9223372036854775807 = NULL
And here's the output from tzdata-2021c, which includes the zone merger:
#zdump -v America/Creston
America/Creston -9223372036854775808 = NULL
America/Creston -9223372036854689408 = NULL
America/Creston Sun Nov 18 18:59:59 1883 UT = Sun Nov 18 11:31:41 1883 LMT isdst=0 gmtoff=-26898
America/Creston Sun Nov 18 19:00:00 1883 UT = Sun Nov 18 12:00:00 1883 MST isdst=0 gmtoff=-25200
America/Creston Sun Mar 31 08:59:59 1918 UT = Sun Mar 31 01:59:59 1918 MST isdst=0 gmtoff=-25200
America/Creston Sun Mar 31 09:00:00 1918 UT = Sun Mar 31 03:00:00 1918 MDT isdst=1 gmtoff=-21600
America/Creston Sun Oct 27 07:59:59 1918 UT = Sun Oct 27 01:59:59 1918 MDT isdst=1 gmtoff=-21600
America/Creston Sun Oct 27 08:00:00 1918 UT = Sun Oct 27 01:00:00 1918 MST isdst=0 gmtoff=-25200
America/Creston Sun Mar 30 08:59:59 1919 UT = Sun Mar 30 01:59:59 1919 MST isdst=0 gmtoff=-25200
America/Creston Sun Mar 30 09:00:00 1919 UT = Sun Mar 30 03:00:00 1919 MDT isdst=1 gmtoff=-21600
America/Creston Sun Oct 26 07:59:59 1919 UT = Sun Oct 26 01:59:59 1919 MDT isdst=1 gmtoff=-21600
America/Creston Sun Oct 26 08:00:00 1919 UT = Sun Oct 26 01:00:00 1919 MST isdst=0 gmtoff=-25200
America/Creston Mon Feb 9 08:59:59 1942 UT = Mon Feb 9 01:59:59 1942 MST isdst=0 gmtoff=-25200
America/Creston Mon Feb 9 09:00:00 1942 UT = Mon Feb 9 03:00:00 1942 MWT isdst=1 gmtoff=-21600
America/Creston Sat Jan 1 06:00:59 1944 UT = Sat Jan 1 00:00:59 1944 MWT isdst=1 gmtoff=-21600
America/Creston Sat Jan 1 06:01:00 1944 UT = Fri Dec 31 23:01:00 1943 MST isdst=0 gmtoff=-25200
America/Creston Sat Apr 1 07:00:59 1944 UT = Sat Apr 1 00:00:59 1944 MST isdst=0 gmtoff=-25200
America/Creston Sat Apr 1 07:01:00 1944 UT = Sat Apr 1 01:01:00 1944 MWT isdst=1 gmtoff=-21600
America/Creston Sun Oct 1 06:00:59 1944 UT = Sun Oct 1 00:00:59 1944 MWT isdst=1 gmtoff=-21600
America/Creston Sun Oct 1 06:01:00 1944 UT = Sat Sep 30 23:01:00 1944 MST isdst=0 gmtoff=-25200
America/Creston Sun Apr 30 08:59:59 1967 UT = Sun Apr 30 01:59:59 1967 MST isdst=0 gmtoff=-25200
America/Creston Sun Apr 30 09:00:00 1967 UT = Sun Apr 30 03:00:00 1967 MDT isdst=1 gmtoff=-21600
America/Creston Sun Oct 29 07:59:59 1967 UT = Sun Oct 29 01:59:59 1967 MDT isdst=1 gmtoff=-21600
America/Creston Sun Oct 29 08:00:00 1967 UT = Sun Oct 29 01:00:00 1967 MST isdst=0 gmtoff=-25200
America/Creston 9223372036854689407 = NULL
America/Creston 9223372036854775807 = NULL
It is possible to build tzdata with PACKRATDATA=backzone if historic pre-1970 data is needed.
Technically, merging time zones also created the potential to break downstream applications. Members of the Java community were very active in the discussion, expressing concerns about breaking Java and historical data loss.
Daylight saving time changes
As September approached, the upstream project needed to release an update to support the announcement that Samoa would no longer observe DST. This resulted in an uptick in discussions, including a proposal to branch the upstream project, replacing the upstream coordinator, and raising the issue with the governing committee.
On September 25, tzdata-2021b was released upstream with several merged zones. More populated zones were preserved while less populated ones were moved to backzone.
Very shortly thereafter, on October 1, another update—tzdata-2021c—was issued upstream to fix compatibility issues raised as a result of tzdata-2021b. Given the ongoing discussions, the upstream coordinator also reverted several previously applied changes to allow more time for discussion. Red Hat preempted tzdata-2021b out of concern for the reported compatibility issues and instead shipped tzdata-2021c.
On October 11, the upstream project was notified that Fiji had suspended DST for the 2021/2022 season. This required yet another update: tzdata-2021d, released upstream on October 15.
On October 18, while Red Hat Engineering was preparing and testing tzdata-2021d for release, the upstream project was notified that Palestine planned to begin wintertime on October 29, rather than on October 30 as had previously been predicted. On October 22, the upstream project released tzdata-2021e to support this change. Red Hat Engineering preempted tzdata-2021d to focus resources on tzdata-2021e, and Red Hat shipped tzdata-2021e on October 26.
tzdata updates in 2022
There are still ongoing upstream discussions related to merging time zones, pre-1970 data, the use of backward links, and the expected time zone database interfaces. Hopefully, these will be resolved in 2022.
For the latest Red Hat tzdata updates, follow the Red Hat Enterprise Linux Timezone Data (tzdata) Development Status Page.