Y2038 Problem

[richlander]

In the spirit of collaboration, we wanted to share that the Y2038 problem is affecting .NET and thought it might also affect manylinux.

Recently, we tackled a similar problem as manylinux solves and looked at your project for (very useful) inspiration. Thank you! In tradition of "paying it forward", we wanted to give you a heads up on this problem and of our solution.

• Breaking change: .NET 9 is Y2038 compatible (Arm32 glibc); .NET 8 is not dotnet/core#9285
• Updated RID Plan dotnet/runtime#83246

If this problem doesn't affect manylinux, then sorry for the interruption.

[sbomer]

https://github.com/dotnet/runtime/blob/main/docs/design/features/y2038.md describes the approach we took for .NET, in case it's helpful.

[ncoghlan]

I believe Y2038 is one of the reasons the Linux ecosystem is aggressively dropping i386 support (it natively uses 64-bit time on x86_64 and other 64-bit architectures).

Checking https://en.wikipedia.org/wiki/Year_2038_problem#Implemented_solutions, it looks like it is has been possible to opt-in to 64-bit time on 32-bit Linux for the past few years.

However, manylinux itself has sidestepped the problem by dropping its i686 image as of manylinux_2_28: #1277

If i686 support were to be brought back, ideally the image would be set up to build with 64-time by default, but aside from that, I think this can be closed as not applicable (still a good thing to check, though!).

[ncoghlan]

Checking the other part of the issue reported in the .NET feature description, they support mixing 64-bit time_t builds of .NET with 32-bit builds of other components (notably OpenSSL).

That would only need to be taken into account for manylinux if i686 images were reintroduced (and IMO counts as a decent argument against ever bringing those images back)

[richlander]

Also, I guess manylinux doesn't support Arm binary wheels.

The whole intent was share our findings in the case that it was useful. It appears like it doesn't apply to Python. That's good! I'll close the issue since I think we have more clarity. If that's not quite right, then folks can follow whatever is the best process for this repo.

[ncoghlan]

It was definitely worth checking, as if manylinux_2_28 hadn't dropped the i686 images, I think they would have posed a potential problem.

The Python ecosystem in general may still run into the problem, though (e.g. https://www.piwheels.org/ ship 32-bit ARM binaries)

Edit: I passed the reminder along in piwheels/piwheels#347

[richlander]

That's very helpful. Thanks! We definitely did not have that context.