y2038: tests should not be failing if system date is set further than year 2037ish

[kanavin]

I did this

To test the readiness of Yocto stack for Y2038 we run qemu virtual machines with RTC set to some day in 2040. This causes many of curl's tests to fail on both 32 bit and 64 bit systems: the reason is that curl's test cookies seem to set their expiry date to 2037 or so.

I would propose to set the expiry date to far enough in the future that it won't have to be tweaked in our lifetimes: this way real Y2038 issues in curl (or in things it depends on) can be exposed and fixed (it's well possible there are none, but that needs confirmation too).

Failures seen:
TESTFAIL: These test cases failed: 31 46 53 61 62 172 179 327 329 420 1104 1216 1415

If there's agreement on this, I can prepare the patch.

I expected the following

I expected 100% pass rate, same as when virtual machine's RTC is set to today.

curl/libcurl version

8.2.0

operating system

Linux qemux86-64 6.1.38-yocto-standard #1 SMP PREEMPT_DYNAMIC Thu Jul 6 18:52:54 UTC 2023 x86_64 GNU/Linux

[bagder]

Going beyond 2037 for dates in tests requires a > 32 bit time_t, which then means that the tests need to either exclude other platforms or they need to be written with conditions. I never bothered with either of those.

I don't know how common systems with small time_ts are.

[kanavin]

All 64 bit architectures already use 64 bit time_t. Also more recent 32 bit platforms, like 32 bit risc-v do. Those are not going to be affected.

The problems are in legacy 32 bit: x86, arm, mips and ppc. On those, the userspace stack needs to be recompiled with '-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64', or dates after 2038 cannot be represented. Yocto has already made this transition, other distros have either abandoned 32 bit computing altogether (Red Hat, Ubuntu), or are trying to come up with a mass-rebuild plan (Debian). I'd say it's okay for the tests to fail on 32 bit platforms which are not ready for Y2038, as that will highlight the problem for them.

[bagder]

All 64 bit architectures already use 64 bit time_t

No they don't but all modern 64 bit architectures probably do.

Also more recent 32 bit platforms

Right. But as you might know, curl builds and is used widely also on old legacy platforms.

I'd say it's okay for the tests to fail on 32 bit platforms

I strongly disagree.

[kanavin]

On 32 bit platforms which are not ready. People need to fix this stuff, and they need to fix it now.

[bagder]

The people who build curl on legacy platforms might not be the people who can do anything about their time_t problems so we would be inserting pain to the wrong people.

[kanavin]

I mean, I can of course locally patch curl tests to not fail beyond 2037 and re-run the tests, but I'm surprised you don't want to do it.

[bagder]

I did not say that. I say it needs to be done correctly.

[bagder]

BTW, test 517 already verifies a few dates way after 2038 and before 1900.

[kanavin]

BTW, test 517 already verifies a few dates way after 2038 and before 1900.

Does it? https://github.com/curl/curl/blob/master/tests/data/test517

[dfandrich]

Yes: https://github.com/curl/curl/blob/master/tests/libtest/lib517.c#L136

[kanavin]

0001-tests-update-cookie-expiry-dates-to-far-in-the-futur.patch.txt

For reference, here's a patch that allows tests to pass in year 2040 on x86_64 Linux (I didn't get to testing 32 bit yet - just making a clean reference point first). It's all made of adjusting dates to far in the future.

[bagder]

If you want to work on fixing dates for curl testing in the future, then please submit your work as a PR!

[bagder]

This is not actually a bug so I'm closing this issue. It is also being worked on in #11610