5 ms·

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.

chungy 4y ago
Yes and no. 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.
- habibur 4y ago
  Tried the following code on Linux / 64 bits. #include <time.h> #include <stdio.h> int main(){ printf("%d\n",sizeof(time_t)); } $ gcc -o time time.c $ ./time $ 8 Therefore time_t is 8 bytes at least on 64 bit systems, even when you are using default time_t and not time64_t. No idea when it was changed. 20 years back?
  - panzi 4y ago
    That changed when GCC compiled to 64bit binaries. Try again with -m32 or -march=i686
    - habibur 4y ago
      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.
      - Jorengarenar 4y ago
        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.
      - panzi 4y ago
        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.
  - toast0 4y ago
    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.
    - masklinn 4y ago
      > 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.
    - dmoreno 4y ago
      Any widely used disk format still uses 32-bit epoch? Somehow I thought of FAT.. but UNIX epoch does not make so much sense...
      - lifthrasiir 4y ago
        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.
ninjin 4y ago
It is not on OpenBSD since OpenBSD 5.5 [1] (there is even a catchy release song about it [2]) which was released in March 2014. Hopefully the patches for the ports tree being upstreamed have started to nudge the general open source ecosystem in the right direction. [1]: https://www.openbsd.org/55.html https://www.openbsd.org/55.html [2]: https://www.openbsd.org/lyrics.html#55 https://www.openbsd.org/lyrics.html#55
jmclnx 4y ago
NetBSD i386 bit moved to a 64 bit time_t and they added some logic for 32bit time_t binaries to still work. 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.

chungy 4y ago

Yes and no. 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.

habibur 4y ago
Tried the following code on Linux / 64 bits. #include <time.h> #include <stdio.h> int main(){ printf("%d\n",sizeof(time_t)); } $ gcc -o time time.c $ ./time $ 8 Therefore time_t is 8 bytes at least on 64 bit systems, even when you are using default time_t and not time64_t. No idea when it was changed. 20 years back?
- panzi 4y ago
  That changed when GCC compiled to 64bit binaries. Try again with -m32 or -march=i686
  - habibur 4y ago
    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.
    - Jorengarenar 4y ago
      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.
    - panzi 4y ago
      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.
- toast0 4y ago
  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.
  - masklinn 4y ago
    > 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.
  - dmoreno 4y ago
    Any widely used disk format still uses 32-bit epoch? Somehow I thought of FAT.. but UNIX epoch does not make so much sense...
    - lifthrasiir 4y ago
      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.

ninjin 4y ago

It is not on OpenBSD since OpenBSD 5.5 [1] (there is even a catchy release song about it [2]) which was released in March 2014. Hopefully the patches for the ports tree being upstreamed have started to nudge the general open source ecosystem in the right direction. [1]: https://www.openbsd.org/55.html https://www.openbsd.org/55.html [2]: https://www.openbsd.org/lyrics.html#55 https://www.openbsd.org/lyrics.html#55

jmclnx 4y ago

NetBSD i386 bit moved to a 64 bit time_t and they added some logic for 32bit time_t binaries to still work. 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.