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

[Jan van den Ende]

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

[Ian Miller.]

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.

[Edwin Gersbach_2]

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]

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

[Garry Fruth]

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.

[Ian Miller.]

enabling audit log entries for time changes is a good idea as it will pick up time changes whatever does it.

[Jan van den Ende]

Ian,

I think you under-valued Garry's response.
I just never noted the functionality, but I will activate it for sure!!

Garry, please enter the "Martin head covered" thread and I will (ab)use it to give you my appeciation for a very useful, very easy implementable pointer.

Cheers.

Have one on me.

Jan

[Ian Miller.]

auditing time changes is a good thing, I know - I do it already :-) If Gary comes back more points will be issued.

[Guinaudeau]

Although this thread is titled for Summer 2004, so the past DST->STD "warp", I am interested to use it to exchange further experiences for both STD->DST and DST->STD warp and at least for VMS 7.3-2 with latest patch levels (UPDATE V4.0, DNVOSIMUP01, TCPIP_ECO V5.4-154). I have seen recently more troubles with STD->DST warp (+1 hour) than with the DST->STD warp.

=> forgotten to close it, or intentionally let opened for this discussion to continue ?

[Ian Miller.]

forgot to close it :-)

A discussion of this topic would be interesting. The start of summer time this year seemed to pass for most people without trouble.

The end of summer time when the clocks go back is generally more troublesome.