Extra time for 2008 - NTP

[Kevin Raven (UK)]

The time keepers of the world , have given us an extra second this year.
I will spend my extra second drinking and making another 2.5 million red blood cells.

Question :
We use NTP on a 4 node OpenVMS 7.3-2 ES45 cluster.
We run at GMT time all year.
Our time sync is a cisco switch.

When we gain the extra second and the clocks appear on the OpenVMS servers are 1 second fast, I guess we will drift the time to get back into synch.
Am I correct ?

We don't want a sudden jump of a second backwards.

I understand the time on the 31st of December 2008 will go like ...

23:59:58
23:59:59
23:59:60 <--- Extra free second

Also will OpenVMS Engineering being providing a patch to cover the day getting shorter by 1 hour in 50 million years time ?


Thanks

Zone Logicals on our cluster -

"SYS$TIMEZONE_DAYLIGHT_SAVING" = "0"
"SYS$TIMEZONE_DIFFERENTIAL" = "0"
"SYS$TIMEZONE_NAME" = "GMT"
"SYS$TIMEZONE_RULE" = "GMT0"

[H_Bachner · Accepted solution]

Hi,

> When we gain the extra second and the clocks appear on the OpenVMS
> servers are 1 second fast, I guess we will drift the time to get back into
> synch.
> Am I correct ?

Yes. Within some (configurable) limits, NTP will drift the time, yielding a monotonous (sp?) growing sequence of time.

> Also will OpenVMS Engineering being providing a patch to cover the day
> getting shorter by 1 hour in 50 million years time ?

I doubt this would be covered by Standard Support. You might ask (and pay) for Extended Engineering Support to fix this problem. :-)

Hans.

[Robert Gezelter]

Herr Bachner,

With all due respect, I believe that the correct word (from mathematics) is "monotonically".

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

OpenVMS time is always drifted forward. The time does not go backwards. The speed at which time progresses is adjusted to add or remove - to drift - the system time. But the time always goes forward.

(Save for the daylight time fall switch-over case, for those areas that still celebrate that particular, um, holiday.)

AFAIK, the OpenVMS TZ definitions do not account for the leap second, and I'd be surprised if there was any provision for this stuff in OpenVMS itself.

If the leap second bothers you, switch from UTC to TAI.

There are various tools which drift the time discussed in the OpenVMS FAQ and elsewhere. IIRC, one called SETCLOCK is around. There are others. Use the copy at http://www.hoffmanlabs.com/vmsfaq - the active web site is currently down due to the ice storm and the ensuing power and network outages. These tools can be used to drift the time forward more quickly, or drift the time forward more slowly, using the system APIs intended for this purpose.

It would not surprise me to see any number of tools and applications could mishandle what should be the correct and full leap second or the :60 specification here, given the amount of stuff that can't handle DSTs. But since there's no leap second in the OpenVMS implementation AFAIK (and you'd have to hit this case to the second), you'll just lose a second against UTC, and all will be well.

If you want a patch from HP for this (and that wasn't a joke), you're asking the wrong crowd. Contact the support center and ask.

[H_Bachner]

Hi Bob,

> With all due respect, I believe that the correct word (from
> mathematics) is "monotonically".

thanks for the correction. As you probably noticed I was unsure about the word, and yes, it not only was a spelling mistake, it was the wrong word at all. My maths lectures at the university were in German...

English is my second language only, and while I'm pretty familiar with terminology in the computer / IT area, I'm still learning in others. Thanks for pointing out the proper word.

Best regards,
Hans.

[John Gillings]

> With all due respect, I believe that
> the correct word (from
> mathematics) is "monotonically".

Perhaps a regional difference in usage? Down here we would describe time as "monotonic increasing". The word "monotonically" seems a bit clumsy.

[Dennis Handly]

>John: Perhaps a regional difference in usage?

Perhaps but goggle finds almost 10X with "monotonically increasing".

For HP-UX, while it allows for leap seconds in struct tm, it assumes they don't exist when computing seconds in a year, etc.