OpenBSD 6.0 ntpctl says "clocked synced" but is ~26 seconds behind
OpenBSD and your VM are working right; you are mis-using the Google time source.
This is in the OpenBSD Frequently Asked Questions and manual pages.
You are synchronizing to a time source that publishes UTC time, sort of. But by default rdate assumes that your time source publishes TAI-10 time. TAI, a strict uniformly increasing count of all SI seconds with always 60 seconds per minute, is currently 36 seconds ahead of UTC, which occasionally discounts so-called "leap seconds". (More accurately: It discounts positive leap seconds; but there hasn't actually been a negative leap second yet.) It will become 37 seconds ahead of UTC at 2016-12-31 23:59:60 UTC, the leap second coming up at the end of this month.
Systems that use TAI rather than UTC actually tend to use what is more accurately known as TAI-10, which is the TAI count shifted into the future by 10 so that it aligns 1970-01-01 00:00:00 UTC, also known as 1969-12-31 23:59:50 TAI, with 1970-01-01 00:00:00 TAI-10.1 This is 26 seconds ahead of UTC, soon to become 27.
Famously, the Google time sources do not count leap seconds. They use smearing which spreads the value of the uncounted extra second across an entire day, and which means that for up to two days per year Google seconds are not a uniform length and are not the same length as an SI second.
rdate needs the -c option to tell it that your time source does not count leap seconds, and you need to use an Olsen "right" timezone that assumes that your kernel clock runs in TAI-10. ("right" timezones and a kernel clock that counts TAI instead of UTC have their advantages.)
Ironically, since you are, too, using Central European Time according to your logs, the example settings given in the OpenBSD Frequently Asked Questions are exactly the ones for you. So read the OpenBSD doco and follow the instructions.
Or: If you want to run in UTC rather than TAI-10, use the "posix" timezones.
1 This is a slightly simplified explanation that involves a commonly used retroactive definition of UTC, and ignores the fact that the UT seconds used before 1972 were variable-length with large table-driven algorithms for converting to/from TAI. But that is beyond the scope of this answer. The situation before 1972 was horrendous. Some people want to do away with UTC and its leap second system and SI second length, and bring that back. They are … misguided.
Further reading
- "Why is my clock off by twenty-some seconds?". OpenBSD Frequently Asked Questions.
rdate. OpenBSD 6.0 Manual.- Christopher Pascoe (2011-09-15). Time, technology and leaping seconds. Google.
- Perry Lorier (2015-07-01).
timeX.google.comprovide non standard time. #437. systemd bug tracker. - Daniel J. Bernstein. UTC, TAI, and UNIX time. cr.yp.to.
- David Madore (2010-12-27). "The TAI−10 setup". The Unix leap second mess.
- https://unix.stackexchange.com/a/294715/5132
26 is a magic number, it is (today) the number of leap seconds added to UTC.
Are you comparing the OpenBSD time with a Debian system which has the "right" zoneinfo files?
TZ=/usr/share/zoneinfo/right/GB-Eire date; date
Thu Dec 1 19:46:16 GMT 2016
Thu Dec 1 19:46:41 GMT 2016
(apologies, I'm only 25 seconds out since I haven't updated my tzdata to account for last year's leap)
The origins of this lie in strict POSIX interpretations of time, of which you can read more here: http://www.ucolick.org/~sla/leapsecs/timescales.html