,
5 tweets,
1 min read
Read on Twitter
Pro-tip: If you are curious as to the exact time when time_t rolls over (the ephocalypse), simply look in your operating system/browser root certificate database 
OpenSSL, last I heard, still uses (time_t) to represent time, so on 32-bit systems with 32-bit time_t, it can't handle certificates with expiration dates past the rollover point, so therefore everyone is avoiding expiration dates past that point.
32-bit Windows has 64-bit time_t for a long while.
32-bit OpenBSD has 64-bit time_t.
32-bit macOS has had 64-bit time_t for a long while.
32-bit FreeBSD on ARM/MIPS has 64-bit time_t -- but strangely not on 32-bit x86.
32-bit QNX has unsigned time_t, so it lasts until 2109.
32-bit OpenBSD has 64-bit time_t.
32-bit macOS has had 64-bit time_t for a long while.
32-bit FreeBSD on ARM/MIPS has 64-bit time_t -- but strangely not on 32-bit x86.
32-bit QNX has unsigned time_t, so it lasts until 2109.
The one big glaring hole is 32-bit Linux, which has 32-bit time_t. Parts of the kernel uses 64-bit time, such as filesystem timestamps and X.509 certificate parsing, but other parts of the kernel remain stubbornly at 32-bit time.
Linux has very good reasons for keeping 32-bit time in 32-bit kernels, because change will break lots of thing you don't expect. But all those very good reasons are wrong as we approach the epochalypse.
