Is it still int32 though? Most of the user space APIs give this value in int64 so I thought kernel would’ve kept it as int64 as well.
If you run modern Linux or FreeBSD even on 32-bit hardware, it does provide time64_t to userspace. Though you will have to compile programs to use time64_t on 32-bit architectures if you so choose. Both kernels have extremely strong senses of backwards compatibility (we're talking of running 30+ years of unmodified Linux and FreeBSD binaries on current iterations), and well, those binaries may or may not have 2038 problems.
#include <time.h>
#include <stdio.h>
int main(){
printf("%d\n",sizeof(time_t));
}
$ gcc -o time time.c
$ ./time
$ 8
No idea when it was changed. 20 years back?
Not quite. Until recently llvm’s time_t was an alias to “long”. So a 32b value on 64b windows.
Somehow I thought of FAT.. but UNIX epoch does not make so much sense...
HFS+ uses a different 32-bit timestamp, which is unsigned and starts from 1904-01-01, so it expires on 2040.
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.
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.
$ gcc -m32 time_size.c -o time_size
$ ./time_size
4
Though I couldn't find anything like `-D_FILE_OFFSET_BITS=64` for `off_t` and associated functions.
OpenBSD i386 went to a 64 bit time_t real soon after NetBSD did.
Both OpenBSD and NetBSD should not have any 2038 issues on 32 bit systems.
FreeBSD i386, I do not know.
Linux 32bit just finished the move in the past year or 2. I do not how complete that is. But I suspect it will be fine.
Others, I have no idea.