Page 1 of 1
DST timezone rules
Posted: Mon Oct 30, 2023 8:57 am
by martinv
Hi!
As the DST-to-STD change has just occured in Germany, I have a bugfix request to make. The TZ database for "Europe/Berlin" contains this timezone rule
which is WRONG (and has been for as long as I can remember). The correct STD-to-DST rule is "M3.
5.0/02" (i.e. not the
fourth, but the
last Sunday in March).
The reason I bring this up is that for the next STD-to-DST change, the error will strike - the change will not be on 24-Mar-2024, but on 31-Mar-2024.
cu,
Martin
Re: DST timezone rules
Posted: Mon Oct 30, 2023 11:20 am
by joukj
Probably wrong for all CEST zones.... same problem with Europe/Amsterdam
Re: DST timezone rules
Posted: Mon Oct 30, 2023 11:53 am
by volkerhalle
Martin,
DECnet/OSI V6.3 for OpenVMS VAX V6.2 has got it right ;-)
Code: Select all
"SYS$TIMEZONE_RULE" = "MET-1MET_DST-2,M3.5.0/2,M10.5.0/3"
Version = "DECnet/OSI for OpenVMS Version V6.3-ECO04 27-JUN-1996 23:36:09.95"
The problem may not be to fix this - can you raise a problem report in the VSI Service Platform ? - but to patch all the remaining OpenVMS systems in the field (at least in Europe) before 24-MAR-2024
Volker.
Re: DST timezone rules
Posted: Tue Oct 31, 2023 3:50 am
by volkerhalle
Pointer to an article on 'Troubleshooting OpenVMS Time zone Issues' from the Digital Technical Journal V17, which describes building timezone rule files:
https://www.zx.net.nz/mirror/h71000.www ... oting.html
Hope this helps,
Volker.
Re: DST timezone rules
Posted: Tue Oct 31, 2023 11:59 am
by madsweeney
I am not saying the problem will not exist but the rule you are looking at is the 2023 rule. On January 1, 2024 the rule will be updated to the 2024 rule. Its possible the 2024 rule will correct the problem. I unfortunately do not have a system that can be used to check the rule update that will happen on January 1.
Re: DST timezone rules
Posted: Tue Oct 31, 2023 1:04 pm
by volkerhalle
Dave,
I'm deeply impressed:
X86VMS $ sho log *time*zone*rule*
"SYS$TIMEZONE_RULE" = "CET^1CEST^2,M3.4.0/02,M10.5.0/03"
X86VMS $ set time=14-jan-2024
X86VMS $ sho time
14-JAN-2024 00:00:02
X86VMS $ sho log *time*zone*rule*
"SYS$TIMEZONE_RULE" = "CET^1CEST^2,M3.5.0/02,M10.4.0/03"
They key seems to be the following lines in SYS$COMMON:[SYS$ZONEINFO.SYSTEM.SOURCES]europe.
Code: Select all
Rule EU 1981 max - Mar lastSun 1:00u 1:00 S
Rule EU 1996 max - Oct lastSun 1:00u 0 -
Thanks for the clarification.
Volker.
Re: DST timezone rules
Posted: Wed Nov 01, 2023 3:24 am
by martinv
Dave,
I'm baffled - I had no idea that the SET TIME command would update the time logicals. Hopefuly this also happens when the regular rollover to 2024 happens.
(Later) No it doesn't, as the following script shows
Code: Select all
$ type timezone_test.com
$ set time="31-dec-2023 23:59:55"
$ loop:
$ show time
$ show logical sys$timezone_rule
$ wait ::1
$ goto loop
$
$ @timezone_test.com
31-DEC-2023 23:59:55
"SYS$TIMEZONE_RULE" = "CET^1CEST^2,M3.4.0/02,M10.5.0/03" (LNM$SYSTEM_TABLE)
31-DEC-2023 23:59:56
"SYS$TIMEZONE_RULE" = "CET^1CEST^2,M3.4.0/02,M10.5.0/03" (LNM$SYSTEM_TABLE)
31-DEC-2023 23:59:57
"SYS$TIMEZONE_RULE" = "CET^1CEST^2,M3.4.0/02,M10.5.0/03" (LNM$SYSTEM_TABLE)
31-DEC-2023 23:59:58
"SYS$TIMEZONE_RULE" = "CET^1CEST^2,M3.4.0/02,M10.5.0/03" (LNM$SYSTEM_TABLE)
31-DEC-2023 23:59:59
"SYS$TIMEZONE_RULE" = "CET^1CEST^2,M3.4.0/02,M10.5.0/03" (LNM$SYSTEM_TABLE)
1-JAN-2024 00:00:00
"SYS$TIMEZONE_RULE" = "CET^1CEST^2,M3.4.0/02,M10.5.0/03" (LNM$SYSTEM_TABLE)
1-JAN-2024 00:00:01
"SYS$TIMEZONE_RULE" = "CET^1CEST^2,M3.4.0/02,M10.5.0/03" (LNM$SYSTEM_TABLE)
1-JAN-2024 00:00:02
"SYS$TIMEZONE_RULE" = "CET^1CEST^2,M3.4.0/02,M10.5.0/03" (LNM$SYSTEM_TABLE)
1-JAN-2024 00:00:03
"SYS$TIMEZONE_RULE" = "CET^1CEST^2,M3.4.0/02,M10.5.0/03" (LNM$SYSTEM_TABLE)
*Interrupt*
$
How is the logical adapted to the 2024 value if no SET TIME is issued?
That said, with the new SYS$TIMEZONE_RULE logical the DST-to-STD rule is wrong again (M10.4.0/03 instead of M10.5.0/3), but that's okay as the fourth Sunday in October 2024 will also be the last Sunday.
cu,
Martin
Added in 18 minutes 57 seconds:
Volker,
nitpicking...
volkerhalle wrote: ↑Tue Oct 31, 2023 1:04 pm
They key seems to be the following lines in SYS$COMMON:[SYS$ZONEINFO.SYSTEM.SOURCES]europe.
Code: Select all
Rule EU 1981 max - Mar lastSun 1:00u 1:00 S
Rule EU 1996 max - Oct lastSun 1:00u 0 -
But in the same file it is stated that these rules only apply to Western and Eastern Europe, while Central Europe uses the "C-Eur" rules (which state the same rules, only in local time):
Code: Select all
Rule C-Eur 1981 max - Mar lastSun 2:00s 1:00 S
Rule C-Eur 1996 max - Oct lastSun 2:00s 0 -
Zone WET 0:00 EU WE%sT
Zone CET 1:00 C-Eur CE%sT
Zone MET 1:00 C-Eur ME%sT
Zone EET 2:00 EU EE%sT
<sigh> There's a reason that the VMS FAQ dedicates a whole chapter to Time and Timekeeping....
cu,
Martin
Re: DST timezone rules
Posted: Wed Nov 01, 2023 6:29 am
by volkerhalle
Martin,
could you run your test until 01-JAN-2024 02:05 ?
There is one TQE for JOB_CONTROL at 1-JAN-2024 02:00:49.21 - this may cause the new time zone for 2024 to be set...
$ ANALYZE/SYSTEM
SDA> SET PROC JOB_CONTROL
SDA> SHOW PROCESS/TQE
...
820F4440 00B91FDE.CE1429A0 1-JAN-2024 02:00:49.21 TSA---
SDA> EXIT
Volker.
Re: DST timezone rules
Posted: Wed Nov 01, 2023 7:55 am
by martinv
Volker,
it does make a change:
Code: Select all
1-JAN-2024 02:00:45
"SYS$TIMEZONE_RULE" = "CET^1CEST^2,M3.4.0/02,M10.5.0/03" (LNM$SYSTEM_TABLE)
1-JAN-2024 02:00:46
"SYS$TIMEZONE_RULE" = "CET^1CEST^2,M3.4.0/02,M10.5.0/03" (LNM$SYSTEM_TABLE)
1-JAN-2024 02:00:47
"SYS$TIMEZONE_RULE" = "CET^1CEST^2,M3.4.0/02,M10.5.0/03" (LNM$SYSTEM_TABLE)
1-JAN-2024 02:00:48
"SYS$TIMEZONE_RULE" = "CET^1CEST^2,M3.4.0/02,M10.5.0/03" (LNM$SYSTEM_TABLE)
1-JAN-2024 02:00:49
"SYS$TIMEZONE_RULE" = "CET^1CEST^2,M3.5.0/02,M10.4.0/03" (LNM$SYSTEM_TABLE)
1-JAN-2024 02:00:50
"SYS$TIMEZONE_RULE" = "CET^1CEST^2,M3.5.0/02,M10.4.0/03" (LNM$SYSTEM_TABLE)
Case closed.
Re: DST timezone rules - Verifying timer queue entries
Posted: Mon Nov 06, 2023 4:25 pm
by charles.williams1@covance.com
If you would like to feel a little more secure that there are actually timer queue entries in place to make the DST changes, this little DCL command procedure will show you. Additionally, it's a nice simple example of using the system analyze utility.