Behaviour of "reload at hh:mm DAY MONTH" over DST change

hunnymonster · ‎10-23-2019

Hello hive mind of the Cisco Community.

I'm planning some scheduled reloads of a fleet of Catalyst 9348 (although this behaviour appears to also be true in a 3850) - to perform the upgrade from IOS-XE 16.6.6 to 16.6.7...

Typically copy the software on, install it using request platform...

request platform software package install switch all file flash:cat9k_iosxe.16.06.07.SPA.bin auto-copy

reload at <time> <date>

However - this time the reload schedule spans the changeover from DST to regular time...

CAT9K#show clock detail
13:32:36.157 BST Wed Oct 23 2019
Time source is NTP
Summer time starts 01:00:00 BST Sun Mar 31 2019
Summer time ends 02:00:00 BST Sun Oct 27 2019

So DST ends at 02:00 on Oct 27...

CAT9K#reload at 01:59 Oct 27
Reload scheduled for 01:59:00 BST Sun Oct 27 2019 (in 84 hours and 26 minutes) by admin on vty0 (8.8.8.8)
Reload reason: Reload CommandReload command is being issued on Active unit, this will reload the whole stack
Proceed with reload? [confirm]

If I reload 1 minute before the summer/wintertime transition then the reload time is still BST (correct) and the time of day for the reload is correct.

CAT9K#reload at 02:01 Oct 27
Reload scheduled for 01:01:00 BST Sun Oct 27 2019 (in 84 hours and 28 minutes) by admin on vty0 (8.8.8.8)
Reload reason: Reload CommandReload command is being issued on Active unit, this will reload the whole stack
Proceed with reload? [confirm]

If I reload 1 minute after the summer/wintertime transition then the reload time is still reported as BST (incorrect) and the time of day for the reload is correct.

I read this that the elapsed time to reload is correct - the reported reload time of day in the new timezone is correct, but the reported timezone is wrong - that's the correct interpretation isn't it?

Leo Laohoo · ‎10-23-2019

Keep it simple.
If DST is configured correctly then the stack will reload based on the time of the switch.
If the calculation of DST confuses anyone then schedule the reload 2 hours before DST.

hunnymonster · ‎10-24-2019

Not really acceptable in this case - this is scheduling for the week ahead, not in the 5 mins before/after DST change, equipment located in a sensitive environment with extremely tight change control and very hard to obtain access and even harder to obtain maintenance windows.

I see that this (display) screw up is fixed in 16.11.1 at least which gives me some comfort that my supposition that the elapsed time before the reload and the scheduled reload time of day reported is correct but the timezone isn't when scheduled over the DST change. I've no doubt that the timezone will be reported correctly after the DST change.