DST change (2)

[Willem Grooters]

Sorry, should habe done this in stead of adding it to an existing thread....

Here's the story.

One of my customers reported a problem due to _switching_ time backward, like seems to happen, given the thread on this subject.
(all times AM, automaticly recorded (= system time...), time is synchronized by external system)
An incident was reported at 2:30, a unit reported "on location" at 2:40, and reported done at 3:15 - but since time changed at 3:00 over here, the recorded time was 2:15. All times are stored as generated.
This causes trouble, of course, when these times are passed to other systems (as we found out) or are being analysed (this incident for instance has a NEGATIVE duration).
_Swtiching_ the clock foreward is less problematic but could impose similar problems.

What would be the best (or less worse) solution here?

Full overhaul of the whole system is out of the question (it concerns a number of (loosely coupled) applications), nor stopping the systems for an hour.

I could adjust time drift, but what would be a reasonable amount?

[Dieter Rossbach]

We use just UTC in missing critical environments, no local time, no DST ...

Regards

Dieter

[Willem Grooters]

Dieter,

That's my idea as well, but then I had to redo all presentations of times - which is off limits ;-(

[Lokesh_2]

I guess nothing can be done here. If choosing UTC is not an option, then application(or reporting tool) should be redesigned to take care of this time change.

Best regards,
Lokesh

[Robert Gezelter · Accepted solution]

Willem,

I second Dieter's motion to use UTC (as do most systems "of record" in defense, aviation, and science). In this type of situation, I wold not, however, recommend the use of the "clock drift" solution.

Presumably, your client's system is used as a legal or business record. Deliberately drifting the clock opens an issue that you DEFINITELY DO NOT want to open, namely the accuracy of your business records, which could have extremely expensive repercussions if your client's firm became involved in an outside dispute, I have seen business records discarded for far less serious discrepancies.

There are several alternatives:

1 - Run the systems on UTC
2 - Select a alternative Standard Time (I run many systems not on UTC. but on Eastern Standard Time (EST) for this very reason, no
Daylight Savings Time Switch).
3 - Convert to DST when displaying
4 - Add a comment to some field in the log record about "time shift in progress"
5 - I do not have the time at this instant, but I think that there is a way to use the time conversion library routines on a process by process (hence, individual user) basis to display appropriately.

All of the UTC/Standard Time solutions do have the hazard that without supplemental software support, historical displays of logs will be an issue (hence the reason why many logs which "logs of record" use UTC (formerly GMT) or do not do the Standard Time/Daylight Savings Time shuffle.

- Bob Gezelter

[Willem Grooters]

Robert,
It's not THAT heavy (Dutch Police). WET as we have set is Ok as a standard, but we do have DST - and that's giving us some trouble - twice a year, sometimes.
I don't think we can do without DST. People just have the _current_time_ in their minds when making their statements, not WET, UTC or whatever standard time you put into the system. In a lot of cases, the exact time is not an issue: taking a statement will take quite a long time so a few minutes more or less won't matter, so a timedrift is not a problem. But alarms, or any incident where immediate action is required can be quite another matter, and the exact moment of signal must be just that: exact. There: no drifting...

However, given the date (which is stored as well), extreme long or short (even negative) durations can be backtraced to DST. (Don't know about the legal implications. hey, good thought - I'll push that forward to the lawyers. Not the first time that that triggers a change....)

Thanks for the support, I had already the impression that it will require quite some effort to prevent this problem.

To conclude - from a technical point of view - for a next system, perhaps ;-)

* Use SOME standard time on your system and do NOT change it (that is: no DTS changes on system time).
* for generated times, don't change them.
* for inputted times, adjust for DST changes
* for output, adjust for DST changes
* times that are exchanged to other systems are to be passed 'as-is' unless the 'other side' has a different idea (which must be VERY clear indeed).

Consider this closed.
Points will be granted.

[Mike Naime]

If you can not switch to UTC time, then you must either shutdown for an hour, or you will have a one hour Overlap. Deal with it!
It's the only way to make everything come out correctly!

Since you ruled out re-writting the application, you are left with the choice of shutting down for an hour, or dealing with the one hour overlap in the other systems that are complaining.

One solution is to schedule an hours "Maintenance" downtime for the change. Because of the maintenance time, you are down for the hour that is affected by the time change. I'm sure that they have scheduled downtimes at some point during the year. Make this one of them.

I know that I was supporting my systems from 00:30 - 05:15 before I set Mikey time back one hour Sunday morning.

[Martin P.J. Zinser]

Hello Willem,

where do you get the time stamps from, Operator log or your own application? If it is the operator log you do not have a chance if you do need to observe DST and do not want to drift (which has is problems, although having a unique timestamp is often more important than the skew. Also if you do know the algorithm used to drift there is a 1:1 relation between reported and real time).

If it is your own application you should be able to switch that to UTC using appropriate RTL functions without having to effect the system time.

Greetings, Martin

[Willem Grooters]

Martin,
Timestamps are "system time" - so taken from the system. In most cases, an approximation is sufficient but for some, the EXACT time might be simply required - and certainly if the sequence of events is extremely important. One of the problems here is that both applications are on differet platfoms
But I now know what to do in a next environment.

[Joseph P. Smith]

Good Morning,

One computerized tool to avoid downtime is Network Time Protocol to slowly skew the time backward and forward.

I run several OpenVMS real-time systems that archive process control data. Nonetheless, we still shutdown, reboot minimum, change time, and then bring up the system with all applications running in the both the spring and fall. This eliminates any ambiguity in determining the "when" of any event.

In the fall we wait for one hour to avoid duplicate data in the same time period. The loss data for one human hour is less harmful than having duplicate entries for a given time period, and then trying to determine what is the "real" event.

So, the most relevant aspects of your problem is customer context, the criticality of system downtime, and the ability of your application software to resolve duplicate time stamps. Your business process has to accomodate for this once a year event, so alternative record keeping may be needed.

Remember that computers provide many solutions, but not all are simple.

Joe S.