DST$CHANGE issue/observation.

[The Brit]

I have seen several references to this over the past week, so I was particularly watching for it on Sat Night/Sunday Morning.

First I ran SYS$EXAMPLES:DAYLIGHT_SAVINGS.COM to generate SYS$MANAGER:DST$CHANGE.COM. Then,

On each of my systems I waited until after 02:00am DST, then ran SYS$MANAGER:DST$CHANGE. On each of my systems the result was the same, vis. the time was changed, but the logicals were not.

Checking the code in DST$CHANGE, it basically seems to execute

utc$time_setup "" "TDF"
followed by
utc$time_setup "" "RULE"

"TDF" should reset the logical SYS$TIMEZONE_DIFFERENTIAL, which it didn't do, and
"RULE" should reset the logical SYS$TIMEZONE_RULE, which it may have done, (I think that the initial string may "EST5EDT4" may have been reversed.)

The interesting thing is that waiting until after 2:00 am EST, and then running utc$time_setup "" "RULE" again, successfully resets all of the logicals. (I determined this on a test system by manually setting the time back forward after running DST$CHANGE, and then manually setting the time back after running utc$time_setup "" "RULE" again.) This seems to resolve the problem.

So the process looks like this; After 2am DST,

$ @TCPIP$NTP_SHUTDOWN ! do this to avoid complications.

$ @DST$CHANGE ! time is set back 1 hour to 1am EST, logicals not reset
$ set time="+1:00:00"
$ @utc$time_setup "" "RULE" ! sets the logicals correctly.
$ set time="-1:00:00" ! Back to EST.

later, @TCPIP$NTP_STARTUP

After completing this process I get;

$ @sys$manager:utc$time_setup "" "SHOW"

: : : :

LOCAL TIME ZONE = US / EASTERN -- STANDARD TIME
LOCAL SYSTEM TIME = 2-NOV-2009 07:47:44.41 (EST)
TIME DIFFERENTIAL FACTOR = -5:00
TIME ZONE RULE = EST5EDT4,M3.2.0/02,M11.1.0/02
Change EST to EDT on the Second Sunday of March (8-Mar-2009) at 02:00
Change EDT to EST on the First Sunday of November (1-Nov-2009) at 02:00

and

$ show log sys*time*

(LNM$SYSTEM_TABLE)

"SYS$LOCALTIME" = "SYS$SYSROOT:[SYS$ZONEINFO.SYSTEM.US]EASTERN."
"SYS$TIMEZONE_DAYLIGHT_SAVING" = "0"
"SYS$TIMEZONE_DIFFERENTIAL" = "-18000"
"SYS$TIMEZONE_NAME" = "EST"
"SYS$TIMEZONE_RULE" = "EST5EDT4,M3.2.0/02,M11.1.0/02"

Having read through the DAYLIGHT_SAVINGS script, I am currious as to whether I would be better off just running

utc$time_setup "" "ALL"

Any Comments.

Dave.

[The Brit]

Additional.

I dont recall having this problem back in March when the clocks went forward. It may only be a problem when the clocks go back!

Dave.

[Richard W Hunt]

On an Alpha running OpenVMS v 8.3 with the automatic time-zone stuff enabled, we changed at the correct time and the logicals changed, too. I didn't have to shut down anything or do anything manual at all. It was nearly transparent.

However, on our two standby nodes (used for disaster recovery), I apparently had not correctly enabled time zone changes so I had to go back and do those by hand. On followup, it was probably because DTSS$CLERK was not running on those two boxes.

Interestingly enough, NONE of the systems in question had SYSGEN parameter AUTO_DLIGHT_SAV set to 1. So that means I have some other logical name missing on our standby systems, and that parameter isn't required for the change if DTSS$CLERK is running. At least, that's the way I interpret what I see.

[The Brit]

Hi Richard,
What you say is correct. If DTSS is running (i.e. you have the DTSS$CLERK process running, then the timechange occurs automatically, including (from what you say) the logicals getting re-defined. The same is true (I assume) if the system parameter AUTO_DLIGHT_SAV is set to 1.

In our case, it would be potentially disasterous if the time was set back 1 hour while our in-house apps were running, so we prefer to keep full control over the process. This is why we depend on the DST$CHANGE script.

I am more concerned by the fact that the script did not perform as advertised (at lease by my understanding).

Dave.

[Hoff]

If time matters to the local processing or if DST can derail local processing, then it can be best to run the servers set to UTC and with DST changes disabled.

[Verne Britton]

My Alpha running 8.2 does the same thing ... that is, I must wait until after 2am EST to do RULE to get the proper results ...

my guess is, the code (or just logic in general) does not know, when in that magic hour between 1am and 2am, if the transition has taken place or not ... so things just do not work right until after the second 2am.

My solution (rather poor) is to simply wait until after the second 2am to do RULE (for me that sometimes means just sitting around the office for an hour in the middle of the night :-) ).


Verne Britton

[The Brit]

Closing the thread. It was just meant to provide an observation and workaround.

Dave.