Discussion:
leap-second.
(too old to reply)
Jan-Erik Soderholm
2017-01-24 21:59:34 UTC
Permalink
Raw Message
Hi.

In another forum there was a general discussion around
leap-seconds and how different computer systems handle it.
There has been reports of crashes and hanging systems that
has needed reboots.

https://en.wikipedia.org/wiki/Leap_second

What about VMS? Has anyone done anything special around
leap-seconds or seen any issues with it?

Jan-Erik.
Michael Moroney
2017-01-25 14:25:55 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
What about VMS? Has anyone done anything special around
leap-seconds or seen any issues with it?
VMS is internally based off the number of 100 nanosecond ticks since
17 Nov 1858, and itself has no concept of leap second. Actual human-
readable dates and times are derived mathematically from that internal
value. I don't know if anything funky has been done in the ntp server on
VMS, I suspect no, which means that the ntp server that was synchronized
will suddenly find itself one second off and will start to skew VMS'
clock to get back in synch.

As to what software based on VMS does, I have no idea.

I have no idea what DTSS does, or if it even matters, as does anyone even
use DTSS to keep VMS systems in time synch these days?
Jan-Erik Soderholm
2017-01-25 15:15:13 UTC
Permalink
Raw Message
Post by Michael Moroney
Post by Jan-Erik Soderholm
What about VMS? Has anyone done anything special around
leap-seconds or seen any issues with it?
VMS is internally based off the number of 100 nanosecond ticks since
17 Nov 1858, and itself has no concept of leap second. Actual human-
readable dates and times are derived mathematically from that internal
value. I don't know if anything funky has been done in the ntp server on
VMS, I suspect no, which means that the ntp server that was synchronized
will suddenly find itself one second off and will start to skew VMS'
clock to get back in synch.
As to what software based on VMS does, I have no idea.
I have no idea what DTSS does, or if it even matters, as does anyone even
use DTSS to keep VMS systems in time synch these days?
So my guess is that the system clock that is based on 17 Nov 1858
is probably adjusted automaticle since NTP time will either pause for
one second or just back one second. There are also solutions where the
NTP server slows down slightly during a longer period (minutes or hours)
so that there will be no sudden pause or jump back in time.

Anyway, that other discussion was that the system clock does not change
at all and the leap second is handled in the presentation layer. This
was not VMS oriented at all, but general.

I guess other features like daylight savings are handled in the
presentation layer, not by adjusting the system clock, right?
Jim
2017-01-25 16:42:34 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
Post by Michael Moroney
Post by Jan-Erik Soderholm
What about VMS? Has anyone done anything special around
leap-seconds or seen any issues with it?
VMS is internally based off the number of 100 nanosecond ticks since
17 Nov 1858, and itself has no concept of leap second. Actual human-
readable dates and times are derived mathematically from that internal
value. I don't know if anything funky has been done in the ntp server on
VMS, I suspect no, which means that the ntp server that was synchronized
will suddenly find itself one second off and will start to skew VMS'
clock to get back in synch.
As to what software based on VMS does, I have no idea.
I have no idea what DTSS does, or if it even matters, as does anyone even
use DTSS to keep VMS systems in time synch these days?
So my guess is that the system clock that is based on 17 Nov 1858
is probably adjusted automaticle since NTP time will either pause for
one second or just back one second. There are also solutions where the
NTP server slows down slightly during a longer period (minutes or hours)
so that there will be no sudden pause or jump back in time.
Anyway, that other discussion was that the system clock does not change
at all and the leap second is handled in the presentation layer. This
was not VMS oriented at all, but general.
I guess other features like daylight savings are handled in the
presentation layer, not by adjusting the system clock, right?
fwiw, the NTP software with the MultiNet IP stack accounts for it...

$ sear multinet:ntpd.log leap
31 Dec 16:00:00 [multinet[540018105]: Positive leap second, stepped backward.
Jan-Erik Soderholm
2017-01-25 17:12:40 UTC
Permalink
Raw Message
Post by Jim
Post by Jan-Erik Soderholm
Post by Michael Moroney
Post by Jan-Erik Soderholm
What about VMS? Has anyone done anything special around
leap-seconds or seen any issues with it?
VMS is internally based off the number of 100 nanosecond ticks since
17 Nov 1858, and itself has no concept of leap second. Actual human-
readable dates and times are derived mathematically from that internal
value. I don't know if anything funky has been done in the ntp server on
VMS, I suspect no, which means that the ntp server that was synchronized
will suddenly find itself one second off and will start to skew VMS'
clock to get back in synch.
As to what software based on VMS does, I have no idea.
I have no idea what DTSS does, or if it even matters, as does anyone even
use DTSS to keep VMS systems in time synch these days?
So my guess is that the system clock that is based on 17 Nov 1858
is probably adjusted automaticle since NTP time will either pause for
one second or just back one second. There are also solutions where the
NTP server slows down slightly during a longer period (minutes or hours)
so that there will be no sudden pause or jump back in time.
Anyway, that other discussion was that the system clock does not change
at all and the leap second is handled in the presentation layer. This
was not VMS oriented at all, but general.
I guess other features like daylight savings are handled in the
presentation layer, not by adjusting the system clock, right?
fwiw, the NTP software with the MultiNet IP stack accounts for it...
$ sear multinet:ntpd.log leap
31 Dec 16:00:00 [multinet[540018105]: Positive leap second, stepped backward.
Does it actually do anything with that informaation? Besdes of reporting
that the "leap second" flag in the NTP package was set. I guess that if
the time on the NTP server jumped back a second in time, the VMS time
did also.

But that is not any different from if the time had been "wrong" for
some other reason, is it?

B.t.w, does NTP (in TCPIP Service or Multinet) do any thing else to
prevent the time to "go backwards"? Or does it just adjust the
time as needed?

I've also seen that a solution that is used, is to slow down the NTP
servers themself during a longer time (minutes or hours) so that the
UTC time always "flows forward" but also gets in sync with the
astronomical time at time for the leap second.

Jan-Erik.
Jim
2017-01-25 19:47:22 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
Post by Jim
Post by Jan-Erik Soderholm
Post by Michael Moroney
Post by Jan-Erik Soderholm
What about VMS? Has anyone done anything special around
leap-seconds or seen any issues with it?
VMS is internally based off the number of 100 nanosecond ticks since
17 Nov 1858, and itself has no concept of leap second. Actual human-
readable dates and times are derived mathematically from that internal
value. I don't know if anything funky has been done in the ntp server on
VMS, I suspect no, which means that the ntp server that was synchronized
will suddenly find itself one second off and will start to skew VMS'
clock to get back in synch.
As to what software based on VMS does, I have no idea.
I have no idea what DTSS does, or if it even matters, as does anyone even
use DTSS to keep VMS systems in time synch these days?
So my guess is that the system clock that is based on 17 Nov 1858
is probably adjusted automaticle since NTP time will either pause for
one second or just back one second. There are also solutions where the
NTP server slows down slightly during a longer period (minutes or hours)
so that there will be no sudden pause or jump back in time.
Anyway, that other discussion was that the system clock does not change
at all and the leap second is handled in the presentation layer. This
was not VMS oriented at all, but general.
I guess other features like daylight savings are handled in the
presentation layer, not by adjusting the system clock, right?
fwiw, the NTP software with the MultiNet IP stack accounts for it...
$ sear multinet:ntpd.log leap
31 Dec 16:00:00 [multinet[540018105]: Positive leap second, stepped backward.
Does it actually do anything with that informaation? Besdes of reporting
that the "leap second" flag in the NTP package was set. I guess that if
the time on the NTP server jumped back a second in time, the VMS time
did also.
But that is not any different from if the time had been "wrong" for
some other reason, is it?
B.t.w, does NTP (in TCPIP Service or Multinet) do any thing else to
prevent the time to "go backwards"? Or does it just adjust the
time as needed?
I've also seen that a solution that is used, is to slow down the NTP
servers themself during a longer time (minutes or hours) so that the
UTC time always "flows forward" but also gets in sync with the
astronomical time at time for the leap second.
Jan-Erik.
AFAIK, it just sets the clock back 1 second at the start of the year (31-Dec-2017 16:00 is 8 hours offset from UTC on this particular system).
Stephen Hoffman
2017-01-28 22:22:33 UTC
Permalink
Raw Message
Post by Jim
AFAIK, it just sets the clock back 1 second at the start of the year
(31-Dec-2017 16:00 is 8 hours offset from UTC on this particular
system).
The leap second can reportedly be inserted at the end of any month, and
previous leap seconds have been inserted at the end of June and
December.
--
Pure Personal Opinion | HoffmanLabs LLC
Michael Moroney
2017-01-29 01:16:33 UTC
Permalink
Raw Message
Post by Stephen Hoffman
Post by Jim
AFAIK, it just sets the clock back 1 second at the start of the year
(31-Dec-2017 16:00 is 8 hours offset from UTC on this particular
system).
The leap second can reportedly be inserted at the end of any month, and
previous leap seconds have been inserted at the end of June and
December.
In order of preference: December, June, March/September, then the other
months.
Stephen Hoffman
2017-01-25 16:52:29 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
What about VMS? Has anyone done anything special around
leap-seconds or seen any issues with it?
VMS is internally based off the number of 100 nanosecond ticks since 17
Nov 1858, and itself has no concept of leap second. Actual human-
readable dates and times are derived mathematically from that internal
alue. I don't know if anything funky has been done in the ntp server
on VMS, I suspect no, which means that the ntp server that was
synchronized will suddenly find itself one second off and will start to
skew VMS' clock to get back in synch.
As to what software based on VMS does, I have no idea.
I have no idea what DTSS does, or if it even matters, as does anyone
even use DTSS to keep VMS systems in time synch these days?
OpenVMS uses the quadword native time from the original design back in
the 1970s as the local time, and the system service API ignores any
localization for the time. That is, the system service API give you
the wrong dates in different geographies for different dates, if you
attempt conversions. The design also does not particularly account
for daylight saving time or locality during conversions, though there
is a mechanism for switching the local time between daylight and
standard time. Altering the time base by an hour plays havoc with
conversions and the storage of the quadword time, too, as the format
omits metadata for the locality and for whether or not DST is active is
not available. Conversions, again, don't tend to account for that as
AFAIK there's no mechanism to set the locality of the requestor within
the native system service API. It'll also fail for the leap second, as
there's no mechanism to account for that value, which means that there
can be a skew of up to 37 seconds in some calculations. Valid time
specifications with the leap second will fail to parse, too. That is,
UTC 23:59:60, or the localtime equivalent of same for OpenVMS sites
using that (e,g, 19:59:60 US Eastern, IIRC), is technically valid, when
a leap second is added, but that's necessarily data driven and thus
tends to run afoul of the more simplistic parsers. I'd expect the
parsers would erroneously accept some other invalid dates, too, such as
the times "between" the switch from standard to daylight.

Further up the stack is the newer UTC system service interface, but few
folks are aware of and fewer still use that API. The UTC API is
usually preferable to the native quadword time API. but it's still
rather clunky and missing more than a few features.

C has the most complete interface here and the C APIs and the DTSS /
DECdtss APIs — that DTSS / DECdtss API was integrated into OpenVMS back
around V6.2 IIRC, and does not require the presence of DECnet — and
these operations are based off of the Olsen database for timekeeping
and timezones, and for performing conversions between same. There
isn't a (reliable) mathematical formula for these conversions, the
calculations are data-driven. This is what the TZ patches generally
update. AFAIK, the OpenVMS implementation does not include the leap
second updates, which means the local time calculations won't reflect
that.

Unix uses a different and simpler approach here, as the system time is
always UTC and the conversions are based on application- or
process-specific settings for locality and DST. Not having to switch
into and out of UTC simplifies the calculations, and helps the
developers and administrators and users recognize the necessary
settings.

Here's a write-up on NTP and leap seconds:
https://www.eecis.udel.edu/~mills/leap.html

Some of the related materials on this topic:
https://www.w3.org/TR/timezone/
http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time

http://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time


As for DECnet and DTSS / DECdtss, that's best left as fodder for a
retirement party, once a deprecation schedule is published, and then
the eventual and wholesale removal of all that.

See the other recent comp.os.vms newsgroup thread for how much of a
mess this is to set up, too.
https://groups.google.com/d/msg/comp.os.vms/8hSJbP01OJ0/PJzdEZ4fAwAJ



TL;DR: OpenVMS timekeeping pretty much assumes localtime and no
timezones and no leap seconds, and has had various changes and
enhancements grafted onto the design over the ensuing decades to try to
ameliorate some of the limitations of the original design. OpenVMS
will fail to parse certain valid time values with the native system
service API (e.g. 23:59:60), might not deal correctly with times that
technically don't exist but that satisfy the parser constraints, and
doesn't account for the leap second. That probably won't effect most
OpenVMS applications (much), though that's more a consequence of not
encountering or otherwise working around the failing cases. It's a
train-wreck, and largely due to compatibility with the original design,
and the ensuing limitations. Those pesky quadword native time values
get stored all over the place. Some apps will crash, some will get
bad data, some will get parser errors for valid times, and the
fundamental design flaws and limitations will probably continue to be
ignored in the interests of maintaining application compatibility.
Folks that need accuracy generally get to account for all these in
their own application code.
--
Pure Personal Opinion | HoffmanLabs LLC
Neil Rieck
2017-02-02 02:22:55 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
Hi.
In another forum there was a general discussion around
leap-seconds and how different computer systems handle it.
There has been reports of crashes and hanging systems that
has needed reboots.
https://en.wikipedia.org/wiki/Leap_second
What about VMS? Has anyone done anything special around
leap-seconds or seen any issues with it?
Jan-Erik.
If you've got your system clock sync'd to a network via NTP then you (the system operator) can choose to jump to the new time -OR- slowly drift to it. Personally speaking, I don't see how changing the clock could crash any computer system. Inserting an additional second into one day might cause a queued batch job to begin one second later than it normally would, but I doubt many applications would be affected by this.

Neil Rieck
Waterloo, Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
Stephen Hoffman
2017-02-02 14:36:44 UTC
Permalink
Raw Message
Post by Neil Rieck
Inserting an additional second into one day might cause a queued batch
job to begin one second later than it normally would, but I doubt many
applications would be affected by this.
Code that's calculating time intervals, for instance can easily have
bugs around leap second handling. That's benign on OpenVMS (for now),
as OpenVMS doesn't implement and knows nothing about leap seconds,
which restricts sources of errors to time values arriving from other
systems that do support leap seconds. The OpenVMS parsers won't allow
23:59:60 or the local equivalent, which is valid for the leap second.

A straight calculation of adding 86400 seconds won't (always) advance
to the next day, or adding sixty seconds or sixty minutes for a minute
or an hour, which means some job runs twice.

OpenVMS lacks a robust mechanism for calculating time intervals — the
DECdtss / DTSS API and an older version of the ICU tools are available
here, though neither is commonly used — which means these errors tend
to be embedded in isolated user-written code. Like Y2K, this won't
effect a whole lot. Some apps will crash, or have untoward behavior.
And the errors and the crashes that do arise either don't get noticed,
or they get ignored. Or they're not even noticed. The sorts of
errors and edge cases that "don't have VMS style discipline", as it's
been phrased.

Put another way, OpenVMS applications processing dates and times
probably won't be any more broken than it already is. Dates and times
are more arcane than many folks realize.
--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2017-02-02 19:34:23 UTC
Permalink
Raw Message
Post by Neil Rieck
If you've got your system clock sync'd to a network via NTP then you (the
system operator) can choose to jump to the new time -OR- slowly drift to it.
Personally speaking, I don't see how changing the clock could crash any
computer system. Inserting an additional second into one day might cause a
queued batch job to begin one second later than it normally would, but I doubt
many applications would be affected by this.
It can screw up the timestamps in applications when the applications
are recording the duration between events (for example, when someone
started doing something and when they stopped).

I know you are only talking about a one second jump above, but in the
general case, sometimes it's far more important for the timestamps to be
internally consistent and of the correct duration than it is for them to
_exactly_ match the external world.

For example, you can use the NTP routines to set the time _once_ outside
of working hours in a batch job (there's a CLI tool you can use for this
in TCP/IP 5.x) and then queue the batch job to run the following day.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Loading...