Test main for failure seen in #7378 for Y2038 bug

[Carreau]

It's unclear to me how the failure seen in #7378
is related to the change in the PR, it just happen that the test need to try touching in 2068.
The 2^32 error in the test makes me strongly think of the year 2038 bug, so I added a test for that.

[github-actions]

GNU testsuite comparison:

Skipping an intermittent issue tests/misc/stdbuf (passes in this run but fails in the 'main' branch)
Congrats! The gnu test tests/misc/tee is no longer failing!

[github-actions]

GNU testsuite comparison:

Skipping an intermittent issue tests/misc/stdbuf (passes in this run but fails in the 'main' branch)
Skipping an intermittent issue tests/timeout/timeout (passes in this run but fails in the 'main' branch)

[Carreau]

Those three failures seem like actual failures / y2038 bugs ?

Which I'm going to guess ends up in the filetime's unix/linux.rs set_times, or utimes.rs, which both call into libc and go beyond my understanding.

[RenjiSann]

I don't understand why this change is in a separated PR from #7378

[Carreau]

#7378 test (and fix) compatibility with gnu touch, i.e. that

• -t 68 (or anything lower) is interpreted as years 2000s
• -t 69 (or anything greater)is interpreted as years 1900s

So really #7378, test the mapping from 2 character years to 4 character years, and could just test parse_timestamp. this mapping is an implementation choice to match gnu touch.

This PR tests that dates just before, at, or just after y2038 bug (even when already a 4 character years) get actually written on filesystem with the correct timestamp (they are not on 32 bits systems). So it tests for a potential bug, independently of whether the year is 2 or 4 characters.

[RenjiSann]

Ok, that makes sense, thanks !