Conversation

@octylFractal this meme is just wrong, no? Linux has used 64-bit time on 32-bit architectures since 5.6, which was released half a decade ago (and it used 64-bit time on 64-bit architectures even way before that)

3
0
0

@sodiboo @octylFractal old 32 bit apps use 32 bit time but they are already broken on many systems

1
0
5

@charlotte @octylFractal sure but that’s… not Linux? meme implies the kernel has this issue?

1
0
1

@piku @octylFractal correct. Linux used 32-bit time representation on 32-bit architectures up until 2020.

0
0
0

@sodiboo @charlotte It was not my intention to indicate the kernel, Tux here is a stand-in for any Linux-based distro.

0
1
2

@octylFractal @atax1a oh thank goodness someone finally fixed the date issue so it was 32 bit signed instead of 31 bit unsigned

1
0
0

@octylFractal @atax1a lmao like every comment on the original is that the rollover is wrong

0
0
0

@sodiboo I don't think it applies much since last year, when Debian finally finished https://wiki.debian.org/ReleaseGoals/64bit-time

But I did have to deal with Java being compiled against 32-bit time APIs on 32-bit systems just this last week, and was resolving an issue with people actively using those systems. So in a general sense, not all Linux systems are actually using it yet, and it still applies in that way.

1
0
0

@octylFractal @sodiboo this isn't a magic fix...it's required to at least rebuild your code against the new libraries, and will probably only work if your code is using only time_t or whatever and not doing dodgy things like explicitly managing it internally as a signed 32-bit int anywhere.

0
0
1