HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Daylight Saving Time to Standard happened twice

 
SOLVED
Go to solution
Clark Powell
Frequent Advisor

Daylight Saving Time to Standard happened twice

I watched the time change take place on an OpenVMS 8.3 system, it went from 1:59:59am to 1 am. about 20 minutes later I rebooted. Apparently, the time change occurred a second time when the system reached 2am again. Is this because I rebooted before passing 2 am standard time or is it a bug?
thanks
Clark Powell
8 REPLIES
Volker Halle
Honored Contributor
Solution

Re: Daylight Saving Time to Standard happened twice

Clark,

it should not have happened, even if you rebooted, so I would consider this to be a bug. But problems in this area are exceedingly hard to report and/or reproduce. A lot of information is required to be able to understand and reproduce your exact scenario.

If you have the ability to report this problem to HP, please collect all the necessary information and do so.

Information to be provided:

- which timezone is your system in
- which patches have been applied
- which time change mechanism is your system using (AUTO_DLIGHT_SAV or DTSS) ?
- OPERATOR.LOG from the time change and reboot
- SHOW LOG SYS$TIME* before and after the time change

Volker.
Clark Powell
Frequent Advisor

Re: Daylight Saving Time to Standard happened twice

Thanks I submitted a ticket to HP. In case anyone on the forum has a comment, here is the additional info you suggested:

FIRST LOG:
%%%%%%%%%%% OPCOM 2-NOV-2008 01:58:13.18 %%%%%%%%%%%
Logfile time stamp

%%%%%%%%%%% OPCOM 2-NOV-2008 01:00:00.13 %%%%%%%%%%%
Message from user SYSTEM on ALPHAC
%TDF-I-TDFSET, Summer time or standard time changeover - new SYS$TIMEZONE_DIFFER
ENTIAL=-28800/old=-25200.

%%%%%%%%%%% OPCOM 2-NOV-2008 01:00:00.18 %%%%%%%%%%% (from node ALPHAD at
2-NOV-2008 01:00:00.18)
Message from user SYSTEM on ALPHAD
%TDF-I-TDFSET, Summer time or standard time changeover - new SYS$TIMEZONE_DIFFER
ENTIAL=-28800/old=-25200.

%%%%%%%%%%% OPCOM 2-NOV-2008 01:09:15.32 %%%%%%%%%%%
$1$DGA5300: (ALPHAC PGB, ALPHAD) has been removed from shadow set.

SECOND AUTOMATIC PDT TO PST CHANGE AFTER REBOOT AT 1:10 PDT:
%%%%%%%%%%% OPCOM 2-NOV-2008 01:32:27.96 %%%%%%%%%%%
Logfile time stamp

%%%%%%%%%%% OPCOM 2-NOV-2008 01:32:35.94 %%%%%%%%%%%
Message from user INTERnet on ALPHAC
INTERnet ACP Deactivate NTP Server

%%%%%%%%%%% OPCOM 2-NOV-2008 01:59:58.80 %%%%%%%%%%% (from node ALPHAD at
2-NOV-2008 01:00:00.09)
Message from user SYSTEM on ALPHAD
%TDF-I-TDFSET, Summer time or standard time changeover - new SYS$TIMEZONE_DIFFER
ENTIAL=-28800/old=-25200.

%%%%%%%%%%% OPCOM 2-NOV-2008 01:00:00.09 %%%%%%%%%%%
Message from user SYSTEM on ALPHAC
%TDF-I-TDFSET, Summer time or standard time changeover - new SYS$TIMEZONE_DIFFER
ENTIAL=-28800/old=-25200.

%%%%%%%%%%% OPCOM 2-NOV-2008 01:07:20.36 %%%%%%%%%%%
Message from user CACHESRV on ALPHAC

LOGICALS TAKEN AFTER THE FACT:
"SYS$DST_DELTA_TIME" = "ffff9cf4be4cd18d"
"SYS$LOCALTIME" = "SYS$SYSROOT:[SYS$ZONEINFO.SYSTEM.US]PACIFIC."
"SYS$TIMEZONE_DAYLIGHT_SAVING" = "0"
"SYS$TIMEZONE_DIFFERENTIAL" = "-28800"
"SYS$TIMEZONE_NAME" = "PST"
"SYS$TIMEZONE_RULE" = "PST8PDT7,M3.2.0/02,M11.1.0/02"

APPARENTLY NTP WAS STOPPED THE SECOND TIME AROUND:
ALPHAC> TCPIP SHO CONFIG ENA SER ntp

Enable service
NTP
Options: None
ALPHAC> TCPIP SHO SERV NTP

Service Port Proto Process Address State

NTP 123 UDP TCPIP$NTP 0.0.0.0 Disabled
ALPHAC>


NTP DRIFT:
TCPIP$NTP.DRIFT;9724
1 2-NOV-2008 01:44:05.25
TYP ALPHAC::SYS$SPECIFIC:[TCPIP$NTP]TCPIP$NTP.DRIFT
-5.815

Re: Daylight Saving Time to Standard happened twice

I can't see how any properly designed OS can have this problem. Especially if the system time is kept in UTC/GMT.
Hoff
Honored Contributor

Re: Daylight Saving Time to Standard happened twice

OpenVMS doesn't manage its time in UTC, which is a design decision at the core of very many of the timezone-related oddities.

I've a fondness for running OpenVMS set to UTC, which means I get the occasional "hey the system time is wrong" as folks first meet the system. (For the most persistent of folks, you could choose to tell them the box is in England and hope they don't know about BST.) But less weirdness.

Zeni B. Schleter
Regular Advisor

Re: Daylight Saving Time to Standard happened twice

I had recently changed an Openvms v7.3-2 host to use the AUTO_DLIGHT_SAV sysgen parameter. Mine also jumped from 2 to 1 twice. It was a system spawned sub-process that triggered the change each time (Audit journal).

I went through support to try to make sure that I had it set up correctly but something was wrong. After untangling the resulting mess, I will log a call.
Clark Powell
Frequent Advisor

Re: Daylight Saving Time to Standard happened twice

It seems that HP is aware that there is a problem but I'm not sure there is really a fix there. Just to execute the UTC$TIME_SETUP.COM correctly is not going to fix this problem. Our TDF$UTC_STARTUP.COM was/is correct. All I can recommend is a warning to all who reboot on time change day in the fall, complete your reboot before the time change or wait a day after if possible. If you must reboot, (and we do,) you'd best do it before 2 am or a day later. Otherwise, be use to use lots of SHOW TIME commands.

Here is HP's response:

I've found a possible fix for this issue which exactly co-relates to one of the scenarios which occured in past.
Since you said that after the first time change happened, you've rebooted the system, which actually executes UTC$TIME_SETUP.COM and recreates the TDF$UTC_STARTUP.COM file controlling the Time Differential Factor, which resides under sys$startup directory when the system startsup.
This effect is also seen after installing either the UPDATE or TZ patch and rebooting the system.
Hence it is recommended to execute the UTC$TIME_SETUP.COM to correctly setup the system to perform time actions properly during system reboot.

To explain the time change occurance precisely, the Day Light Saving is configured by setting the SYSGEN parameter AUTO_DLIGHT_SAV = 1, making the system to auto adjust the day light saving to either +1 or -1 hr depending upon the settings found under TDF$UTC_STARTUP.COM file.
We also recommend disabling AUTO_DLIGHT_SAV on systems with Time Sensitive Applications that start at boottime.
Once the execution of UTC$TIME_SETUP.COM is done to setup the system to perform time actions, this issue could be resolved.
Zeni B. Schleter
Regular Advisor

Re: Daylight Saving Time to Standard happened twice

Their response is clear as mud. Sorry:)
I did not reboot my system in between 1 and 2. Accounting records and Audit logs show continuous flow .

I will print out your posted comment from HP and study it. I have a TDF$UTC_STARTUP.COM created at 1:02 a.m. I also have a procedure that I added for setting the Timezone logicals correctly. The procedure worked as far as I can tell but maybe on the system with Auto_dlight_sav set , it has unexpected results. This procedure does execute the UTC$Time_SETUP but the params are a "" and "RULE" because the point is just to reset the logicals , not change the time.
Looking at the audit records , it looks like the likely culprit in my case is that my procedure runs at 2:00 and does something to the sys$timezone.dat that causes system to act as if the time has not been set back as yet so it does it again.
Clark Powell
Frequent Advisor

Re: Daylight Saving Time to Standard happened twice

I recieved more detail from HP. Their recommendation to clear this problem for reboot later is to delete all the sys$system:sys$timezone*.dat files and run UTC$TIME_SETUP.COM again or risk

I don't know if our files are really this bad but, we will be rebooting on Thursday so I will find out if we change again. In the future, I will be doing the time change manually. I've suffered too much grief for this automatic time change system and since during the time change, I have to shut the application down anyway it makes no sense to suffer through it. My recommendation, if you are already "hands on" at 2 am to nurse your application then change the time on the OS manually; you may end up doing it manually anyway.