Y2038 problems on 32-bit systems with 64-bit time_t

[ijackson]

In Debian trixie (13, as yet unreleased), several 32-bit architectures have been provided with a 64-bit time_t so that they will continue to work after Y2038. I was not involved with this transition, but it seem to have involved inventing __time64 etc. to be used by new programs.

I have been trying to fix faketime in Debian trixie. While writing a test case I discovered that on these architectures, libfaketime.c is comiled in a way that reverts back to the 32-bit time representation. There are some patches floating about to fake the 64-bit calls (which I'll probably incorporate) but they are wrong, because they (must) all eventually call functions like the internal clock_gettime and fake_clock_gettime, and those are all working with 32-bit struct timespec.

I don't think I understand the area well enough to fix this, but I thought I would at least file a ticket. I think the solution will have to involve compiling clock_gettime and fake_clock_gettime (and maybe others) with 64-bit time_t, struct timespec, etc., so that they can be called by interceptors like clock_gettime64 and time64.

See https://wiki.debian.org/ArchitectureSpecificsMemo for a table of affected architectures.

Thanks for your attention.

[ijackson]

Hi. Please reopen this ticket. As I wrote in #487, that MR does not fix this issue!

(I think github has interpreted "this MR does not fix #482" as "please close #482 when this merges, which is totally mad.)