Broken since Rakudo MoarVM 2023.11

[0rir]

With MoarVM Rakudos from 2023.11 to the current 2025.02 Touch fails. Locally, I have fixed a problematic leap second problem in Rakudo.

At least while Rakudo's leap second problem continues to exist, I will try to diagnose the mangling of UTIME_OMIT and UTIME_NOW as it is passed to utimensat. Having no good clue, I will Continue to persevere. Passing now for both is possible but ugly.

[coke]

What is "Rakudo's leap second problem"? Is there a ticket?

[0rir]

.from-posix-nanos and .from-posix don't match when TAI != UTC. See rakudo/rakudo #5800.

[coke]

Tried to test with blin, but the version at HEAD has a bugfix that isn't in the last release version, so instead, I'm manually bisecting with rakubrew versions...

[coke]

@0rir - HEAD doesn't work on raku v2022.03 on my mac - what is your last known good combination of Rakudo and Touch version?

update - I tested on mac, which is known to have issues, see #3

[coke]

On Util's guidance, used only the t/004*, and bisected to 8eee6c397653f09519ff5fe6d3187dc7ec241c16 in Rakudo, unsurprisingly - the change that changed the precision of the Instants returned by IO::Path instants - Because it's still an Instant, that's probably why it was not kept behind a language boundary

[coke]

Looks like TESTLAG is not applying to all the tests. E.g.:

    is $file.IO.accessed, $control, "Setup control access time.";
    is $file.IO.modified, $control, "Setup control modify time.";

# Failed test 'Setup control access time.'
# at t/004-action.rakutest line 36
# expected: 'Instant:-11111'
#      got: 'Instant:-11121'
not ok 4 - Setup control modify time.
# Failed test 'Setup control modify time.'
# at t/004-action.rakutest line 37
# expected: 'Instant:-11111'
#      got: 'Instant:-11121' 

Are there some tests where we expect an exact answer and can have no slack?

[0rir]

Yes, lag is not an issue for the tests of a fixed value. TESTLAG is to cover the delay between storing now and getting a Timespec built and pushed through utimensat().

If it will help, I can make a condensed test with the test data explicitly there with few tests.
Or advise how I may help.

I was not aware of this reversion. My patch is very mundane and simple.

commit 9437aab067d61197ca1e5d9beb5aff66fea8ed2d
Author: Elizabeth Mattijsen liz@raku.rocks
Date: Wed May 14 12:37:28 2025 +0200

Revert "Test and fix that Instant.from-posix-nanos and Instant.from-posix  match"

This reverts commit cd45f4d9ab98bc6671f52351ae4815c8a6d7852d.

Unfortunately, this causes extensive spectest breakage, which escaped
my judgement  :-(

commit cd45f4d9ab98bc6671f52351ae4815c8a6d7852d
Author: rir rirans@comcast.net
Date: Wed May 14 11:19:49 2025 +0100

Test and fix that Instant.from-posix-nanos and Instant.from-posix  match

* Add test that Instant.from-posix and .from-posix-nanos agree

* Fix Instant::from-posix-nanos to include leap-seconds

Thanks.

[coke]

Adding links to those commits:

• rakudo/rakudo@9437aab
• rakudo/rakudo@cd45f4d

[coke]

Opened your commit as a PR: rakudo/rakudo#5927 - as @lizmat noted, it is failing spectests (noted on the draft PR). Once that tests clean, we can get it re-merged.