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

[Sherri Lyon]

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.]

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

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

[Jack Trachtman]

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]

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]

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

[Wim Van den Wyngaert]

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

[Jan van den Ende]

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

[John Gillings]

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)

[Edwin Gersbach_2]

>... 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]

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