Time management is always hard.

I mean, it's hard for ordinary people -- the internets are full of ebooks and tips on how to organize your time, and there are lots of books about the problem. It's also hard for programmers -- you need to take into account different timezones, those timezones can change between countries and years, you need to know when to apply a leap day, UTC leap second, you can't measure duration by snapshotting previous and current time, because the date/time synchronization daemon could kick in any second and can completely change the date in your system.

So, since I've absolutely randomly stumbled upon the date/time synchronization daemon subject...

OpenBSD, in a default installation, uses ntpd to synchronize date/time with a time authority server pointed to by pool.ntp.org dispatcher domain. The problem is that the connection to pool.ntp.org is not secure, and by using it you could be the victim of a man-in-the-middle attack. This is why OpenBSD devs have implemented a "constraint" server configuration option, which allows you to query some public "trusted" server (such as google.com) to verify the time returned by pool.ntp.org.

The problem is that when ntpd tries to contact a "constraint" server, it does this by doing an HTTPS connection. This means that it is negotiating a TLS connection. This, in turn, means that it downloads a certificate and tries to verify it... and when the system time is so wrong that the certificate appears to be from the future, or appears to be expired, the TLS connection initiation fails due to an invalid certificate being used. So ntpd fails to contact the "constraint" server.

And if ntpd fails to contact the "constraint" server, it doesn't perform time synchronization on the system.

So if you happen to be unlucky enough to have your invalid date/time set to a point where current Google certificate is invalid, your OpenBSD system won't be able to update the date/time at all. Well, at least I'm safe from man-in-the-middle attacks! I guess it's up to debate what is more desired, but I think having a proper date/time in the system is (should be) quite important.

The fix was easy; I've just manually set the time to a period where current Google cert is valid, so ntpd could contact the constraint server and verify that the date it got from pool.ntp.org was indeed a proper date. It then proceeded to change my system's date/time to the proper value. In other words, I had to manually perform the work which should be done by ntpd. So what's ntpd for? It works now, but would it work tommorow if I hadn't modify the default config? I don't know.

Security over usability? I'll just leave this here: