topic Let's do the time warp again ! - End of summer time 2004 in Operating System - OpenVMS

Let's do the time warp again ! - End of summer time 2004

Ian Miller. — Sun, 31 Oct 2004 05:52:26 GMT

Any reports of things going wrong this time? Are threaded apps, DCPS and JAVA all behaving themselves now? Did the most recent TDF patch stop all known bugs?

Share your experiance here for the benefit of all.

(I will find out on Monday what worked and what did not as I'm not on call this weekend :-)

Re: Let's do the time warp again ! - End of summer time 2004

David B Sneddon — Sun, 31 Oct 2004 06:54:09 GMT

I use the old SPRINGFOR/FALLBACK stuff from days
long gone... they provide a gradual time change
No problems here.

Regards
Dave

Re: Let's do the time warp again ! - End of summer time 2004

John Gillings — Sun, 31 Oct 2004 21:18:03 GMT

Ian,

No apparent problems on any of our internal systems, and no problems reported to the CSC this year (so far?). Though, down here, we're gone forward, which tends to be less of a problem than turning time backwards.

My personal opinion is that "automatic" daylight savings time adjustements are far more work than just setting the clocks manually! Instead of just setting the clock, you have to make sure the automatic system is correctly set, and check that it worked at the right time.

spring_forward.com
$ SET TIME="+0-1:0"

$ SUBMIT/AFTER="30-OCT-2004 02:00" spring_forward

Re: Let's do the time warp again ! - End of summer time 2004

DICTU OpenVMS — Mon, 01 Nov 2004 02:26:52 GMT

This year it almost went ok... Just don't forget to set the auto_dlight_sav parameter ;-) The systems that had the system parameter set, went 1 hour back and untill now everything seems fine. The other systems we had to set by hand...

Re: Let's do the time warp again ! - End of summer time 2004

Jan van den Ende — Mon, 01 Nov 2004 06:25:00 GMT

So,

it looks like I am the first to report an issue.

- 1 cluster, 7.3-2, TCP/IP 5.4 ECO-2
2 sites, 2 nodes per site. All 4 NTP running, AUTO_DLIGHT_SAV = 1

At 2:58 MC SYSMAN /ENV=CLUSTER DO SHO TIME:
4 times 2:58

3 minutes later same command:
1 site, bath nodes 2:01, other site both nodes 3:01

Be patient, time to go to sleep long past anyway:

At 2:20
1 site 2:20, other site 3:20.
NTP logfiles show no exception whatsoever.

So, I decided to do it by hand.

On node with correct time
MC SYSMAN /ENV=CLUS
DO CONFIG SET TIME

Everything look OK now.

And now for the real surprises:
The NTP logfiles on the nodes that WENT OVER AUTOMATICALLY report SYNCRONISATION LOST after time change, and thereafter report TIME SLEW 3600 secs (+- few /00 secs);
and still have TIME DIFFERENCE 7200 (summer difference); the nodes that were forced by hand report NOTHING exceptional, and time difference in correct at 3600.

We are completely baffled, and already have decided that next year (again) we will NOT let it go unattended. :-(

Cheers.

Have one on me.

Jan

Re: Let's do the time warp again ! - End of summer time 2004

Volker Halle — Mon, 01 Nov 2004 06:47:22 GMT

We had some systems (V7.3-2 running DTSS client) change to normal time (MET) one week too early, because the timezone rule was bad:

"SYS$TIMEZONE_RULE" = "MET-1MET DST-2,M3.4.0/02,M10.4.0/03"

And this year, M10.4.0/03 (= 4th sunday in October) was one week too early. After running @UTC$TIME_SETUP, the correct timezone rule had been set up:

MET-1MET DST-2,M3.4.0/02,M10.5.0/03

and the automatic switch worked fine this weekend (M10.5.0 = LAST sunday in October).

But when looking forward at the switch to DST next March, the rule is still incorrect, as it should say M3.5.0/02 for MET (last sunday in march) - although it won't matter next year (4th sunday = last sunday). Anybody agree ?

Volker.

Re: Let's do the time warp again ! - End of summer time 2004

Volker Halle — Mon, 01 Nov 2004 07:15:39 GMT

Jan,

did you check for OPCOM messages ? I've had success with 2 nodes (E8.2 Alpha and Itanium, NTP client, AUTO_DLIGHT_SAV=1)

%%%%%%%%%%% OPCOM 31-OCT-2004 03:00:00.25 %%%%%%%%%%% (from node I64VMS at 31-OCT-2004 02:00:00.25)
Message from user SYSTEM on I64VMS
%TDF-I-TDFSET, Summer time or standard time changeover - new SYS$TIMEZONE_DIFFERENTIAL=3600/old=7200.

Nothing unusual in TCPIP$NTP_RUN.LOG

Volker.

Re: Let's do the time warp again ! - End of summer time 2004

Antoniov. — Mon, 01 Nov 2004 09:21:52 GMT

Ian,
like John I use a command file to change time. No problem.
I'd like known better how system manage timezone :-)

Antonio Vigliotti

Re: Let's do the time warp again ! - End of summer time 2004

Ian Miller. — Mon, 01 Nov 2004 10:26:16 GMT

Here on pre V7.3 systems not running DECnet/OSI I schedule a batch job which stops NTP and does
$ if f$search("SYS$MANAGER:UTC$CONFIGURE_TDF.COM") .NES. ""
$ THEN
$ @SYS$MANAGER:UTC$CONFIGURE_TDF.COM SET 0 -60
$ ELSE
$ SET TIME="-01:00"
$ ENDIF

then restarts NTP if it was running.

this seems to work for me.

Re: Let's do the time warp again ! - End of summer time 2004

Dieter Rossbach — Mon, 01 Nov 2004 10:29:09 GMT

My two DEBIAN systems changes the time correctly. but my MVS systems ....

All my test systems are on VMS 7-3.2, latest patch level, some hat the correct time, some didn't, but that had nothing do do with sys$timezone-differential (one correct system had 3200, the other had 7200) or with auto_dlight_save (on of the correct systems had 0, one with the wrong time had 1)

On my costumer systems, I did all by hand (no: by command procedure)

Regards

Dieter

Re: Let's do the time warp again ! - End of summer time 2004

Sherri Lyon — Mon, 01 Nov 2004 16:52:32 GMT

OK, so the last time I posted was about this same subject! We don't use the system parameter (auto_dlight_sav), just a command procedure that runs on all of our systems.

We did manage to get the timezone_differential set correctly on all machines by using the following:@sys$manager:utc$time_setup "" TDF -360 0

But, on all of our Alphas (7.3-1 & up), there are 2 additional logicals: sys$timezone_daylight_saving and sys$timezone_name that were NOT changed. Can I just redefine those logicals in my command procedure, or is there some other command-line based way of updating them?

And, if someone would give a quick explanation of the 'auto_dlight_sav' param, maybe we could start using that on our Alphas.

Thanks so much!
Sherri

Re: Let's do the time warp again ! - End of summer time 2004

Ian Miller. — Mon, 01 Nov 2004 17:11:41 GMT

Sherri, long time no post - nice to see you back :-)

Do you have DECnet/Plus installed?
Is DTSS enabled?

Re: Let's do the time warp again ! - End of summer time 2004

Jack Trachtman — Mon, 01 Nov 2004 17:31:36 GMT

TCPIP V5.4 ECO 2

Just starting to investigate this problem (have spoken w/HP)...

On some of my systems, I restarted NTP as part of the time change. But then NTP could not access our internal NTP server!

After some digging, HP found that the NTP file and directory owner did not match with the NTP account in AUTHORIZE, so the NTP exe could not access the directory to create its log file which caused it to hang on startup. Supposedly the NTP startup code will sometimes (why?) change the AUTHORIZE UID!

Today I will be inventorying NTP on all our systems and making sure everything is as it should be.

Re: Let's do the time warp again ! - End of summer time 2004

Garry Fruth — Mon, 01 Nov 2004 17:36:17 GMT

We had some systems in a cluster fall back two hours instead of one. All systems had the same sys$timezone* logicals. All systems use NTP. All systems have DTSS disabled. ES80s in the cluster fell back correctly. GS1280s fell back one hour twice; once the first time the clock struck 2am, and again the second time the clock struck 2am.

Re: Let's do the time warp again ! - End of summer time 2004

Kris Clippeleyr — Tue, 02 Nov 2004 04:47:03 GMT

Ian,

No problems seen here.
All our systems (ranging from VMS 7.1-2 to E8.2, DECnet Plus DTSS enabled) all switched nicely.

Kris

Re: Let's do the time warp again ! - End of summer time 2004

Wim Van den Wyngaert — Wed, 03 Nov 2004 07:54:09 GMT

We had bad luck. On 1 cluster an internal product crashed (2 installations failed) while on 10 others clusters it went fine.
No problem with VMS (DTSS changed time).

But when changing to summer time problems are worse : symbionts and webes start to loop and the internal product crashes from time to time (irony : it's called BEST !).

Wim

Re: Let's do the time warp again ! - End of summer time 2004

Jan van den Ende — Wed, 03 Nov 2004 08:53:55 GMT

And all this misery because time goes back...

Wim:
I _AM_ surprised you got more problem going forward than going backward...

Apart from the time-change itself, which DTSS appears to do a lot smoother than NTP, most problems I have met in the past stem from the fact that several (mostly database) systems do not really like to present or modify information that has been created in the future. (sounds like stuff for SF :-)

....
This goes MUCH further than just IT:

Ever since the intro of DST (for Holland, somewhere in the 1970's) I have been wondering about the (in my view stupid, and unnecessary) hour that occurs twice.
Many processes, procedures, legal issues, etc, depend on the order in which events happen in time.
So, what is earlier, 2:45 or 2:15?
Looks so easy, and normally IS easy, EXCEPT when after 2:45, at 3:00 you change the time to be 2:00 again, and after that 2:15 comes to pass.

Why not, once a year, add the 25th hour?
Adding an extra hour is done anyway, but now it is done by duplicating the 3rd hour.

(for the example I use this year, of course the intention is generic)

Let saturday october 30 last until 25:00.

Yes, any mechanical clock still has to be reset from 1:00 to 0:00, but for any REGISTRATION, the first clock-time 0:45 is given as october 30, 24:45, and only after 24:59:59, the next second it will be october 31, 0:00:00.

Result: any timestamped events will have been stamped in correct chronology.

... just wondering if this kind of (in my view, much more elegant) implementation of DST was really so hard to think up?.....

Probably will forever remain a philosofical issue now.

Cheers

Have one on me.

Jan

Re: Let's do the time warp again ! - End of summer time 2004

John Gillings — Wed, 03 Nov 2004 20:41:34 GMT

Jan,

>... just wondering if this kind of (in
>my view, much more elegant) implementation
>of DST was really so hard to think up?....

Although attractive from a conceptual & aesthetic perspective, this would be a disaster for IT systems. Consider the way dates and times are represented - basically as an offset in some unit from a specific base date. Although the units and base dates vary, this is how they all work.

Now, given a particular value, we can use a single, non-varying algorithm to work out what date and time it represents (granted it's a fairly complex algorithm with different length months and leap years, but it is fixed).

The trouble with your scheme is we would need to refer to varying tables to calculate the date and time, and it would depend on your location. To some extent this issue already exists when converting times from one zone to another, but with your "25th hour" it would occur for ALL time calculations.

For countries like the USA where daylight savings time zone rules are practically written into the constitution(!) this isn't much of a problem, but for us in Australia where time zone rules change on a very regular basis, it's a nightmare (check out the ZIC files for Australasia and see how many times the rules have changed in the last decade)

Re: Let's do the time warp again ! - End of summer time 2004

Edwin Gersbach_2 — Thu, 04 Nov 2004 01:57:37 GMT

>... just wondering if this kind of (in
>my view, much more elegant) implementation
>of DST was really so hard to think up?....

It would have been even more easy!

The core of the whole problem is that the system time gets changed at all. I don't mean that we should get rid of DST (that discussion has to take place somewhere else) but - as some operating systems do it actually - let the system clock run contiguously, just change the TDF (Time Differential Factor), and all is set. Time stamps in logfiles and the like should include the TDF anyway to allow them to get compared with events in other geographical regions. You then have 02:15 (2) and 02:15 (1) or the like while databases and timing related applications would use the internal (UTC) time.

Edwin

Re: Let's do the time warp again ! - End of summer time 2004

Wim Van den Wyngaert — Thu, 04 Nov 2004 02:39:52 GMT

Another solution : change the speed of time. Make the system clock go faster/slower in such a way that 1 day takes 1 hour more/less.

This already happens when synchronizing the clock with DTSS.

But all "non-IT" clocks must be replaced.

Wim