Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

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

Ian Miller.
Honored Contributor

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

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 :-)
____________________
Purely Personal Opinion
29 REPLIES
David B Sneddon
Honored Contributor

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

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

Regards
Dave
John Gillings
Honored Contributor

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

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

A crucible of informative mistakes
DICTU OpenVMS
Frequent Advisor

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

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...
Jan van den Ende
Honored Contributor

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

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





Don't rust yours pelled jacker to fine doll missed aches.
Volker Halle
Honored Contributor

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

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.
Volker Halle
Honored Contributor

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

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.
Antoniov.
Honored Contributor

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

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

Antonio Vigliotti
Antonio Maria Vigliotti
Ian Miller.
Honored Contributor

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

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.
____________________
Purely Personal Opinion
Dieter Rossbach
Regular Advisor

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

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
Sherri Lyon
Occasional Visitor

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

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
Ian Miller.
Honored Contributor

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

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

Do you have DECnet/Plus installed?
Is DTSS enabled?
____________________
Purely Personal Opinion
Jack Trachtman
Super Advisor

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

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.
Garry Fruth
Trusted Contributor

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

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.
Kris Clippeleyr
Honored Contributor

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

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
I'm gonna hit the highway like a battering ram on a silver-black phantom bike...
Wim Van den Wyngaert
Honored Contributor

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

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
Wim
Jan van den Ende
Honored Contributor

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

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
Don't rust yours pelled jacker to fine doll missed aches.
John Gillings
Honored Contributor

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

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)

A crucible of informative mistakes
Edwin Gersbach_2
Valued Contributor

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

>... 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
Wim Van den Wyngaert
Honored Contributor

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

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
Wim
Jan van den Ende
Honored Contributor

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

John,

I fail to see why "my" algoritm would make the calculation for display-time from base + offset any more complex: in the current situation that same hour comes into the calculation, only activated just 2 hours later (and that moment is decuced from the DST time rule specifying logical anyway).

Edwin,
yes, of course that would be MUCH better for IT systems (and becoming ever more important; consider multi-site clusters spread over different timezones!)
Still the issue of timestamps in the "double" hour remains, on IT systems for the display, in eg. legal documents like burth certificates, or crime investigation reports, etc. Your way of annotation it looks (to me) much more ugly than the occurrence, once a year, of 24:15 as moment in time.

Wim,

changing the speed of the clock is a good, and often used, trick to ensure smooth flow of time, ie, to prevent discontinuaty.
It wreaks havoc on timestamping though!! (and that for the whole duration of the modified speed situation, which of course takes (much?) longer than the hour that needs to be tricked in or out).
Consider my current job: any "incident" in the police call room is time-stamped by the OS. I do not know the Belgian legal system that well, but at least in Holland, should a case come to court and the timing is (or can by lawyers be made into! ) an issue, that immediately is the end of the prosecution.
Not really that much appreciated in THIS organisation!!

Cheers.

Have one on me.

Jan


Don't rust yours pelled jacker to fine doll missed aches.
Ian Miller.
Honored Contributor

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

personally I think system time should stay on UTC or some other fixed time. What the users see could be changed to show local time depending on where they are. This would require knowing the locale of each each user or parhaps where they are today for travelling users.

This is not often considered for applications. With a VMS cluster it could be possible to have different parts of the cluster in different time zones but you have to run the cluster on one timezone.
____________________
Purely Personal Opinion
Edwin Gersbach_2
Valued Contributor

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

Jan,

> Still the issue of timestamps in the
> "double" hour remains, on IT systems
> for the display, in eg. legal documents
> like burth certificates, or crime
> investigation reports, etc. Your way of
> annotation it looks (to me) much more
> ugly than the occurrence, once a year,
> of 24:15 as moment in time.

While it may look somewhat ugly (or maybe just not familiar?) it includes information which becomes more and more important. You mention crime investigation: how do you determine a local time when you get a mail from Australia about a phonecall? Do you know for each town there what time zone it is in? Ask a US citicen what timezone Lettland is in! You have to have this information from one source or another, so why not supply it in a generic manner?

Edwin
Jan van den Ende
Honored Contributor

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

Edwin,

of course!

And the decent way to do that you can see implemented in the heading of each posting in this forum.
Yes, I too am of the opinion that the STORED computerized timestamp, and any international time reference, should be UTC!!
But that still leaves the weird way to handle local time as having to different moments of the same identification...

Cheers.

Have one on me.

Jan
Don't rust yours pelled jacker to fine doll missed aches.
Garry Fruth
Trusted Contributor

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

Regarding my earlier post about the clocks on gs1280s falling back twice. It took us a while to figure out what happened.... A rather old maintenance procedure, untouched in several years, did a SET TIME/CLUSTER nightly at 2am. I'll won't bother explaining the split second timing details.

BTW, I would suggest turning on time audits and alarms, that is how we eventually found the cause.

We did note some odd behavior on machines running Multinet XNTP. They are probably misconfigured; still researching. Some fell back one hour; a few minutes later went forward an hour, and an hour later fell back an hour. This almost went unnoticed; however, I started using the audit logs to see if there were any other problem areas.