2038 is closer than it seems

Posted May 22, 2014 5:50 UTC (Thu) by eru (subscriber, #2753)
Parent article: 2038 is closer than it seems

I hope going to 64-bit time_t is selected, like the BSD:s did. Given the human tendency of putting off chores with no immediate benefit, harshly imposing the fix when code is recompiled is the only way to get this solved before the deadline.

to post comments

2038 is closer than it seems

Posted May 22, 2014 9:55 UTC (Thu) by arnd (subscriber, #8866) [Link]

My feeling is that at the kernel interface side, we won't do a hard break, and keep 32-bit time_t at least for the architectures that have it today while introducing new syscalls to take to the libc.

What user space does is a different matter though. I think you should always have at least the option to build a libc that only supports 64-bit time_t in user space and that uses the new kernel interfaces for a safe implementation. This way, an enterprise distro with e.g. 10 years of guaranteed support and lots of legacy third-party applications can keep working as previously, while an embedded system with 25 years support and no legacy code can go to 64-bit time_t in user space without any backwards compat hacks in user space.