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
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
Here's a write-up on NTP and leap seconds:
Some of the related materials on this topic:
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.
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