Or, if your built-in clock really is unstable (which is common in both very old and new machines; some x86-64 chipsets are famous for having crap timers), then it could be just wobbling all over the place rapidly, jumping many hours at a stretch. I’ve seen heavy CPU usage throw off the internal clock, too, which made me wonder just what timer was being used, for the CPU cycles to throw it off so much! Certain chipsets with buggy ACPI implementations can also throw off the timer, since the CPU speed shifts can do funny things to the cloc,.

You may want to take a look at your kernel configuration and see which timers or RTC you’re using — most computers have more than one. The kernel config options explain this a bit further in their help screens (press ?). If you have an HPET timer available, it’s often a good idea to use this, as it’s generally a very stable, high-resolution timer.

If you get the chance, may I ask one more thing? I have noticed that occasionally, if I pick up an exceptionally fresh upload from another time zone and try to compile it, I get occasional errors of the same nature. Is that a possibility too? Can the times stamped from someone else’s source files trigger clock skew warnings on a machine in a different time zone? Perhaps I’m reaching, but I could swear one time that was the case.

Often, the hardware manufacturer sets the hardware clock to UTC, and the operating system can either use that — align itself to the UTC time — or it’s free to ignore it and go on “local” time. Local time is the time you set manually, either during installation or during normal desktop usage.

Machines that dual-boot Windows with Linux are famous for hitting this issue because Windows uses local time, while most Linuxes like using UTC. To avoid the issue, the Linux install has to be set to “local” in /etc/conf.d/clockor equivalent.

I notice this happening on my dual-boot Gentoo/Ubuntu laptop. I have my clock in Gentoo set to “local”, as I’m using the PST8PDT timezone. Ubuntu seems to be using something more UTC-like, like America/Los_Angeles, which is not the same TZ. Thus, whenever I go to Gentoo from Ubuntu, I’ve got disk errors and checking to do, as the OS thinks it’s now in the future. Etc.

Normally, just syncing up timezone and clock configs between environments should fix the issue. If software fails, perhaps you’ll have additional options in your BIOS? And if that fails, perhaps you do, indeed, have hardware issues.

I should say though that these seem to crop up between booting into a live CD and chrooting into a system I’m troubleshooting, and when I boot directly into the system.

Of course this machine is so old it might be having hardware problems too.

Your hardware must be having serious issues if it’s getting that much clock skew while just compiling.