Slewing time instead of one hour "fall"ing back

[Paul Edward Johnson]

We have a situation where we time stamp our processes and in the "spring" forward of daylight savings time it does not effect us because we do not end up with duplicate time stamps. At the end of daylight savings time when we "fall" back one hour we end up with duplicate timestamps. Has anyone successfully 'slew'ed their systems through the fall or found a way (other than shutting the systems down for an hour) to keep from receiving duplicate time stamps - but still getting back "on time" quickly?

[A. Clay Stephenson]

Only because of poor design do you wind up with "duplicate" timestamps because
"01:59:59 CDT" is distinctly different from
"01:00:00 CST"; your are simply not being precise enough when you omit the timezone.
The best solution is to not shift the time at all and choose a TZ value that does not change. Doing a step change is not an option because you could easily have a situation in which transaction 101 occurs before transaction 100.

Your best options are therefore to:
1) modify your applications to include the TZ
or
2) choose a TZ that does not shift

Since you aren't going to do either of those, you are really left with 2 choices. Shutting down for hour or slewing the time. It will take several hours for time to slew that much --- during which your time will be wrong although internally consistant.

[A. Clay Stephenson]

Ooops, I'm stupid I meant to say: "01:59:59 CDT" is distinctly different from
"01:59:59 CST".

[Bill Hassell]

And you can't slew the time time fast enough to adjust an hour in less than 24 hours. A 10 minute change requires 3-4 hours to complete. Slewing will slightly reduce or increase the time between seconds so that there will be exactly 86400 seconds every day. But 60 minutes is a massively long time and tools like NTP simply refuse to try to sync that time change.

HP-UX only keeps time in UTC (aka, Zulu or GMT) and never changes time for Daylight Saving. Instead, standard Unix libraries honor the $TZ variable and translate the time to (political) timezones with adjustments for Daylight Saving where local politics defines the rules.

As Clay said, a well written program that requires a time stamp must be written with Daylight Saving provisions or better yet, use GMT for all program timestamps. date -u will return GMT as will: TZ=GMT0 date. If you set TZ in your program to TZ, the time will always be correct and will have no skips. You can then translate the time to show to humans in their local timezones.

[Paul Edward Johnson]

I agree with everything that has been said. But, trying to change the timezone in our environment is not something that can be completed accross the board in anything less than YEARS.

I appreciate your comments - just preaching to the choir. I was hoping for a very creative "out the the box" solution that someone may have seen out in the field...