> Meanwhile, the unsigned 32-bit count of seconds (also) since 1970 used in pcap output from tcpdump, and used universally throughout the financial industry wit

> Meanwhile, the unsigned 32-bit count of seconds (also) since 1970 used in pcap output from tcpdump, and used universally throughout the financial industry with no hint of a move away from it, will not roll over until 2106. If they are still in use then, code will interpret small values as implying a time after 2106, rather than as an ancient historical time before 2000. The format would need to change before 2106, because I'm pretty sure that the time is stored as a big-endian encoded value -- to expand it requires changing the format. There really is nothing revolutionary about using an unsigned value, it just delays the problem by 80 years. Yeah, it's not something we'll have to worry about but our (great-)grandkids will. > It is hard to know why anybody thought it so urgent to go to 64-bit seconds counters for internal use in the kernel. There are many digital infrastructure projects which are planning to ship today's Linux for the next few decades (think things like traffic lights, as is the case in Japan). Fixing the 2038 problem now is necessary, because those deployments won't be updated until it's too late. But more importantly, the UAPI used to represent time as a 32-bit integer so it's necessary to replace those syscalls with new versions -- and you need to give enough time for userspace to migrate. The same problem of deployed software equally applies here. And if you're going to fix the UAPI you might as well fix the problem entirely.