- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- DST change (2)
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-30-2003 09:58 PM
10-30-2003 09:58 PM
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?
OpenVMS Developer & System Manager
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-30-2003 10:21 PM
10-30-2003 10:21 PM
Re: DST change (2)
Regards
Dieter
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-30-2003 10:34 PM
10-30-2003 10:34 PM
Re: DST change (2)
That's my idea as well, but then I had to redo all presentations of times - which is off limits ;-(
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-30-2003 10:39 PM
10-30-2003 10:39 PM
Re: DST change (2)
Best regards,
Lokesh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-30-2003 11:56 PM
10-30-2003 11:56 PM
SolutionI 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-31-2003 01:42 AM
10-31-2003 01:42 AM
Re: DST change (2)
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.
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-31-2003 11:13 AM
10-31-2003 11:13 AM
Re: DST change (2)
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-31-2003 02:00 PM
10-31-2003 02:00 PM
Re: DST change (2)
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-02-2003 06:25 PM
11-02-2003 06:25 PM
Re: DST change (2)
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.
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-05-2003 12:03 AM
11-05-2003 12:03 AM
Re: DST change (2)
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.