If your system has no or non-working battery-powered clock, time will be
incorrect until NTP runs.  If you have no network connectivity before
xscreensaver starts, this can mean a sudden jump by several years.
I guess those who suffer from MS Windows and don't use that undocumented
registry hack may see jumps by an hour due to time zone handling too.

When a forward jump happens, xscreensaver locks the screen.

As I understand, using clock_gettime(CLOCK_MONOTONIC) instead would fix this
problem.

If you have a *tested* patch, please send it.

I don't have any systems that exhibit the kind of broken behavior you describe, and can't test it myself. This is very security-sensitive code so I am hesitant to make any changes at all without them being very obviously correct.

It's also important that you understand and explain what systems this affects and how to properly detect that it is available, if the routines you are calling are not POSIX.

timers.c:check_for_clock_skew() is what you're looking for. However it is only called every pointerPollTime seconds (default 5) and even then only if /proc/interrupts exists. (Which I suppose means that the clock skew check never happens on BSD?)

Also note that if the wall clock moves backwards, XtInterval timers completely fail to fire until the clock catches up. This is an unfixable failure in the bowels of Xt.

It's great to know that even here in This Modern World, trying to close the lid on a Linux laptop and have anything work is still slapstick comedy. What year is this?

I don't know that code, and as you say yourself it is security sensitive.
I can give it a try if you wish, though.

These days, a good deal of arm-based stuff don't ship a RTC chip.  Usually
because adding a battery is expensive, but since this machine is a laptop
that already has a battery, I kind of fail to understand why.

After boot-up, the clock is set to 2010-01-01.  For obvious reasons, I
installed ntp, but network is not always available.  If it comes up after
I log in (wifi coverage, AP selection, etc), the clock will suddenly advance
by multiple years.

I guess you can duplicate this by moving aside /etc/init.d/hwclock.sh
(I can't check if that's enough right now).

Or by setting the clock a few years back in the BIOS.

man clock_gettime says it's specified in SUSv2 and POSIX.1-2001; there might
be other functions that could be used for this purpose.

I've seen multiple machines with broken RTC, including x86 ones (a broken
/depleted battery is enough), fortunately in every case it resetted to a
time in the past.

This bug is not related to the lid.

My clock say 2010.  [screen lock].  Oh, 2013.