NetBSD also has 64 bits time_t, even on 32 bits arch.
Since version 6.0 (17 Oct 2012), actually:
https://www.netbsd.org/releases/formal-6/NetBSD-6.0.html
"time_t is now a 64-bit quantity on all NetBSD ports. This means that the NetBSD world no longer ends in 2037." 🤓
@ParadeGrotesque @brynet @solene @paul And that even without breaking the ABI thanks to versioning :).
@js @solene @ParadeGrotesque @paul Ah yes, hence NetBSD's mythical major library crank wishlist, ~30 years and counting.. 
http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/lib/libc/shlib_version
OpenBSD was able to do a bunch of namespace cleanups thanks to being able to actually break ABI, remove functions, occasionally, rather than hide all the legacy and warts behind symbol versioning.
@js @solene @ParadeGrotesque @paul OpenBSD was able to move to using an explicit Symbols.list file, which is very clean these days.
@ParadeGrotesque @brynet @solene @paul
When we started the OpenBSD 64bit time_t work, the ports team found that lots of 3rd party software didn't handle time_t==long long correctly and had to push upstream lots of fixes.
That left some of us wondering about the ports experience for NetBSD in that time range: did NetBSD just patch those all locally and not upstream them? What happened that the knowledge you guys sweated for there didn't get spread? 
@brynet Yeah, as always, I'm quite jealous of the OpenBSD project's ability to just ship it and break API/ABI here because it's correct -- it's a bit more tricky for us where the vast majority of software running in Debian is outside the project's control here and changes become conservative, sprawling and arduous quickly.
OpenBSD is in better shape today as a result of that decision, and I don't think Debian's i386 port is going to be particularly fun to maintain as we get closer to y2038.