I have now seen my first ever year 2038 bug. An embedded Linux system that was installed two years ago became unable to acquire a network address by DHCP. The machine did not require an accurate clock, and nobody had initialised its battery-backed real-time clock. Once installed, it had started counting forward from 1st January 1900.
32 bit Unix time covers a range from December 13th 1901 to January 19th 2038. As the real-time clock value was outside this range, Linux wrapped the time round to the year 2036. After the machine had been running for nearly two years, it passed through the 2038 rollover and jumped back to 1901.
This would have been harmless in itself if all the applications on the machine used a monotonic clock, such as the uptime counter returned from the sysinfo function. But the machine in question used an older version of Busybox, and the udhcpc DHCP client in that release failed when faced with a time in the negative number range before 1st January 1970.
The moral of the story? Even though a machine doesn’t need a real-time clock function, it may not be immune to clock related bugs.