Re: Morocco's time is inconsistent between the rearguard mode and the vanguard mode
It only changes FORMAT from +01/+02 to +01/+00, but the rearguard should be +00/+01. And gmtoff is still 7200. After the patch is installed, rearguard mode: [root@ localhost ~]# timedatectl Local time: Mon 2026-06-29 03:40:52 +00 Universal time: Mon 2026-06-29 01:40:52 UTC RTC time: Mon 2026-06-29 01:43:58 Time zone: Africa/Casablanca (+00, +0200) System clock synchronized: no NTP service: active RTC in local TZ: no vanguard mode: [root@localhost ~]# timedatectl Local time: Mon 2026-06-29 02:40:57 +01 Universal time: Mon 2026-06-29 01:40:57 UTC RTC time: Mon 2026-06-29 01:44:02 Time zone: Africa/Casablanca (+01, +0100) System clock synchronized: no NTP service: active RTC in local TZ: no The attached patch fixes the above bug.
Thanks, I installed that, followed by the attached minor update which shouldn't change the output of ziguard.awk today, but which I hope lessens the likelyhood of future glitches like this.
When stdoff is used for judgment, the value of stdoff is incorrect when it is switched from the rearguard mode to the vanguard mode. The value should be 1:00, but the actual value is 0:00. Test steps: 1. make VERSION=2026b ZFLAGS="-b fat" tzdata2026b-rearguard.tar.gz.t 2. tar xvf tzdata2026b-rearguard.tar.gz 3. make DATAFORM=vanguard all vanguard.zi: # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone Africa/Casablanca -0:30:20 - LMT 1913 Oct 26 0:00 Morocco %z 1984 Mar 16 1:00 - %z 1986 0:00 Morocco %z 2018 Oct 28 3:00 0:00 Morocco %z 2026 Sep 20 2:00 0:00 - %z
If the NF is used for judgment, there will be a problem too. In vanguard mode, the value of stdoff from 1986 to 2018 will increase by 3600.
Do we need to consider the scenario where it is switched from the rearguard mode to the vanguard mode? If yes, is it better to use the year for judgment, as follows: diff --git a/ziguard.awk b/ziguard.awk index 79df9bef..9d846af2 100644 --- a/ziguard.awk +++ b/ziguard.awk @@ -286,7 +286,7 @@ DATAFORM != "main" { } } } - if ($1 ~ /^[+0-9-]/ && stdoff == 60) { + if ($1 ~ /^[+0-9-]/ && $4 == "2026") { if (DATAFORM == "rearguard") { sub(/1:00\tMorocco/, "0:00\tMorocco") sub(/\t\+01\/\+00/, "\t+00/+01")
On 2026-06-29 01:03, Liu Chao via tz wrote:
Do we need to consider the scenario where it is switched from the rearguard mode to the vanguard mode?
Yes, that's the idea. I was working along the same idea as you, and installed the attached slightly-bigger patch; please give it a try. By the way, what do you need rearguard for? Is this for Java, or something else?
Paul Eggert wrote:
On 2026-06-29 01:03, Liu Chao via tz wrote:
Do we need to consider the scenario where it is switched from the rearguard mode to the vanguard mode? Yes, that's the idea.
I was working along the same idea as you, and installed the attached slightly-bigger patch; please give it a try. It works, thanks.
By the way, what do you need rearguard for? Is this for Java, or something else? One reason is for Java. At the same time, it is also to keep the same as other OS vendors (such as RHEL). If switching from rearguard to vanguard now, it might affect upper-layer third-party softwares and require a significant amount of time to explain the differences between these changes.
On 2026-06-29 01:35, Liu Chao via tz wrote:
I was working along the same idea as you, and installed the attached slightly-bigger patch; please give it a try. It works, thanks.
Thanks for checking; glad to hear that things work now.
By the way, what do you need rearguard for? Is this for Java, or something else? One reason is for Java. At the same time, it is also to keep the same as other OS vendors (such as RHEL). If switching from rearguard to vanguard now, it might affect upper-layer third-party softwares and require a significant amount of time to explain the differences between these changes.
Yes, and Java is the primary reason we still have rearguard format. Eventually I'd like to delegate the maintenance of rearguard format to the Java folks (assuming they still need it then) as it is a pain to maintain (as witness our emails in this thread!) and they're the only ones I know who still need it - which is why I asked about Java. As I understand it, although older versions of RHEL used rearguard format, the current version (RHEL 10) uses the main format. So eventually RHEL's need for the old format should go away.
For example, the glibc contains a global variable timezone, which is the opposite value of the gmtoff value in the last line of the timezone with isdst=0. In some time zones, the values of timezone in rearguard and vanguard modes are different.
Yes, just as tm_isdst differs. That's fine, and is expected.
I have seen some softwares directly add or subtract the timezone value to convert the local time to the UTC time.
Any such software is broken, because 'timezone' is the difference between local time and UT during only part of the year, and this is true regardless of whether rearguard format is used. So this issue shouldn't lead to a preference for rearguard format - unless the goal is to reproduce old bugs. Anyway, as you probably know, 'timezone' does not suffice for proper timekeeping, which is why 'timezone' is planned to be removed in a future version of POSIX. See <https://data.iana.org/time-zones/theory.html#functions> and look for "POSIX features no longer needed". So any problem with rearguard and 'timezone' will go away eventually.
Paul Eggert wrote:
By the way, what do you need rearguard for? Is this for Java, or something else?
One reason is for Java. At the same time, it is also to keep the same as other OS vendors (such as RHEL). If switching from rearguard to vanguard now, it might affect upper-layer third-party softwares and require a significant amount of time to explain the differences between these changes. For example, the glibc contains a global variable timezone, which is the opposite value of the gmtoff value in the last line of the timezone with isdst=0. In some time zones, the values of timezone in rearguard and vanguard modes are different. I have seen some softwares directly add or subtract the timezone value to convert the local time to the UTC time. If the mode is switched from rearguard to vanguard, the time calculation will be incorrect.
participants (3)
-
liuchao (CR) -
liuchao173＠huawei.com
-
Paul Eggert