time_t was almost certainly 64-bit on 64-bit archs from the beginning. There's just a lot of 32-bit stuff still out there. And here and there a disk format standarized before people started thinking about the end of time.

> time_t was almost certainly 64-bit on 64-bit archs from the beginning.

Not quite. Until recently llvm’s time_t was an alias to “long”. So a 32b value on 64b windows.

Any widely used disk format still uses 32-bit epoch?

Somehow I thought of FAT.. but UNIX epoch does not make so much sense...

Up to ext3 are using 32-bit timestamps. Ext4 now uses 34-bit, by extending only the upper range, and can cope with 7 * 2^32 seconds after the epoch, which is around 2446.

HFS+ uses a different 32-bit timestamp, which is unsigned and starts from 1904-01-01, so it expires on 2040.

That changed when GCC compiled to 64bit binaries. Try again with -m32 or -march=i686

Doesn't even compile with -m32. Asks for a missing header, which google indicates to install from a i386 library.

I regularly compile a lot of stuff on this machine, indicating I never needed that before.

So none of the software I compiled had 32 bit time_t. And we still have 15 more years to migrate anything remaining behind.

You explicitly tell the compiler to compile against 32-bit library, but since you don't have one installed, it doesn't compile. If somebody compiles 32-bit program which doesn't require additional dynamic libraries and ships that binary, you won't even know until it fails in 2038.

And as you yourself noticed, `time_t` on 64-bit machine is also 64-bit, so even if code was written on 32-bit architecture, if you compile it on 64-bit one, it will automatically become 64-bit.

Works for me:

    $ gcc -m32 time_size.c -o time_size
    $ ./time_size 
    4

But I have the 32bit development packages installed (besides the 64bit pkgs). Am on Fedora.

Though I couldn't find anything like `-D_FILE_OFFSET_BITS=64` for `off_t` and associated functions.