fs: preserve negative utimes timestamps

[GiHoon1123]

toUnixTimestamp() converted negative numbers to the current time, while negative strings and Dates were handled correctly.

Keep numeric timestamps unchanged and add coverage for negative values.

On AIX, negative timestamps are unsupported, so the test skips that platform-specific case while retaining the coverage on supported platforms.

Fixes: #64597

[GiHoon1123]

Just checking in on this one when you have a chance. No rush.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/76160/

[trivikr]

aix72-power9/aix73-power9 CI is failing

not ok 1913 parallel/test-fs-utimes
  ---
  duration_ms: 444.51200
  severity: fail
  exitcode: 1
  stack: |-
    node:internal/assert/utils:146
      throw error;
      ^
    
    AssertionError [ERR_ASSERTION]: FAILED: expect_ok [Arguments] {
      '0': 'utimes',
      '1': '/home/iojs/build/.tmp.1913',
      '2': [Error: EINVAL: invalid argument, utime '/home/iojs/build/.tmp.1913'] {
        errno: -22,
        code: 'EINVAL',
        syscall: 'utime',
        path: '/home/iojs/build/.tmp.1913'
      },
      '3': '123456',
      '4': -1
    }
         check_mtime: -1787339819
        at expect_ok (/home/iojs/build/workspace/node-test-commit-aix/nodes/aix72-power9/test/parallel/test-fs-utimes.js:64:3)
        at /home/iojs/build/workspace/node-test-commit-aix/nodes/aix72-power9/test/parallel/test-fs-utimes.js:111:5
        at /home/iojs/build/workspace/node-test-commit-aix/nodes/aix72-power9/test/common/index.js:511:15
        at FSReqCallback.oncomplete (node:fs:185:23) {
      generatedMessage: false,
      code: 'ERR_ASSERTION',
      actual: false,
      expected: true,
      operator: '==',
      diff: 'simple'
    }
    
    Node.js v27.0.0-pre
  ...

[GiHoon1123]

Thanks for flagging this. It looks like AIX rejects negative timestamps outright, so this needs a bit more investigation than just adjusting the test. I won't be able to look into it right away, but I'll follow up when I can.

[guybedford]

Following up on the thread here, simply skipping AIX explicitly in the test via common.isAIX seems completely fine - negative times only make sense on platforms that support them anyway.

@GiHoon1123 are you still interested in seeing this one through? Alternatively I could pick this one up as well.

[GiHoon1123]

I am still interested in seeing this through. I added the AIX-specific skip for the negative timestamp case and pushed a follow-up commit. I also updated the PR description to note the platform-specific behavior.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/78083/

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.35%. Comparing base (00917ba) to head (6cb3923).
⚠️ Report is 1319 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #64627      +/-   ##
==========================================
+ Coverage   90.14%   90.35%   +0.21%     
==========================================
  Files         741      792      +51     
  Lines      242076   275495   +33419     
  Branches    45558    52791    +7233     
==========================================
+ Hits       218216   248933   +30717     
- Misses      15385    16985    +1600     
- Partials     8475     9577    +1102     

Files with missing lines	Coverage Δ
lib/internal/fs/utils.js	96.27% <ø> (-1.65%)	⬇️

... and 485 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[guybedford]

For the remaining Windows failure this seems to be a limitation of not having full 64 bit time, so all negative epoch times on Windows are reported as post 2038 times instead!

Unfortunately no easy way to fix that without having support for 64 bit time in libuv.

A few options:

1. Skip this on Windows for now
2. Fix libuv so that negative epoch times under our 32 bit time are pre-epoch not post 2038.
3. Actually support 64 bit time in libuv so we don't have this issue

3 is the right fix, 2 is a good stopgap. But given the responses I've had to libuv PRs recently I'm really not sure we can rely on any fix being possible here.

[guybedford]

Correction, it seems Node.js was the one that decided to allow post-2038 times on Windows only utilizing the negative time range for this.

Therefore this is in fact a decision that Node.js could turn around on and decide to align with POSIX in treating negative times as negative epoch not in the future.

Since this is a rarely-used Windows specific behavior, I'm tempted to say that that is the correct fix - changing the behavior of the test in test-fs-utimes-y2K38.js to no longer support post-2038 times on Windows.

[GiHoon1123]

The Windows behavior where a negative epoch is interpreted as a wrapped 32-bit future date appears to be a separate, pre-existing design decision, covered by the overflow_mtime case in test-fs-utimes-y2K38.js.

This PR’s new negative-timestamp assertion is simply the first test to reach that path on Windows, since toUnixTimestamp() previously converted negative numbers to the current time.

Would it be reasonable to skip the new negative-timestamp assertion on Windows for now, as we do on AIX, and discuss changing the existing behavior separately with input from the relevant collaborators?

Alternatively, would you prefer that this PR also remove the existing Windows overflow_mtime assertion and update the related test coverage? I’m happy to follow whichever scope is preferred.

[guybedford]

I honestly think it would be worth rethinking that previous design decision here for Windows and changing that test-fs-utimes-y2K38.js so that negative Windows times are pre-epoch not post-2038, but it's also not clear yet if that will be possible.

Perhaps @LiviaMedeiros or others can share their thoughts if they think this is something we can change at this point. I struggle to see how anyone would be relying on post-2038 times in Node.js using this technique though.

[jasnell]

I think changing it is reasonable. I think it likely has to be semver-major, however.