fs: add Temporal.Instant support to Stats and BigIntStats

[LiviaMedeiros]

Refs: #57891

This is a very rough draft, and probably shouldn't land until Temporal implementation is finalized and/or enabled by default.
Opening early to see if there are any objections, suggestions to naming (the *Instant properties are facing userspace and having consistent convention would be nice), or to implementation.

[Renegade334]

Since Date.prototype.toInstant() comes along with Temporal, these are fairly trivial to obtain anyway? (Although come to think of it, this would lose nanosecond precision.)

It might be better to have this as a switchable option similar to bigint, rather than adding the overhead of building a load of Temporal objects for every stats call?

[LiviaMedeiros]

Since Date.prototype.toInstant() comes along with Temporal, these are fairly trivial to obtain anyway?

Converting from Date would have performance overhead on top of precision loss.

It might be better to have this as a switchable option similar to bigint, rather than adding the overhead of building a load of Temporal objects for every stats call?

These properties are lazy-loaded, so the overhead when not used should be minimal.

[aduh95]

We're probably going to want to support building node without Temporal support for a while

Suggested change

	// TODO(LiviaMedeiros): TemporalInstant primordial
	return new Temporal.Instant(BigInt(MathFloor(msec / kMsPerSec)) * kNsPerSecBigInt + BigInt(nsec));
	if (Temporal == null) throw 'informative error';
	// TODO(LiviaMedeiros): TemporalInstant primordial
	return new Temporal.Instant(BigInt(MathFloor(msec / kMsPerSec)) * kNsPerSecBigInt + BigInt(nsec));

[LiviaMedeiros]

Agreed, especially with mandatory Rust requirements.
Added the error, the message text is subject to changes (if this may land before enabling Temporal by default, it should also suggest --harmony-temporal flag)

[aduh95]

Suggested change

	ObjectDefineProperty(this, 'atimeInstant', { __proto__: null, value, writable: true });
	setOwnProperty(this, 'atimeInstant', value);

[LiviaMedeiros]

AFAICT this will make the property enumerable, even though the initial getter is not? I don't mind it, but this better be aligned with how Date setters behave.

[aduh95]

We should probably add an additional optional enumerable argument to setOwnProperty

[aduh95]

The original getter is enumerable though

[codecov]

Codecov Report

❌ Patch coverage is 84.67153% with 21 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.04%. Comparing base (c24e552) to head (b4c96e5).
⚠️ Report is 8 commits behind head on main.

Files with missing lines	Patch %	Lines
lib/internal/fs/utils.js	84.44%	21 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #60789      +/-   ##
==========================================
- Coverage   90.05%   90.04%   -0.01%     
==========================================
  Files         714      714              
  Lines      225247   225375     +128     
  Branches    42578    42582       +4     
==========================================
+ Hits       202842   202949     +107     
- Misses      14181    14202      +21     
  Partials     8224     8224              

Files with missing lines	Coverage Δ
lib/internal/errors.js	97.65% <100.00%> (+<0.01%)	⬆️
lib/internal/fs/utils.js	97.78% <84.44%> (-1.91%)	⬇️

... and 24 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.

[aduh95]

let's avoid the additional setter call

Suggested change

	return this.atimeInstant = instantFromTimeSpecMs(this.atimeMs, this[kPartialAtimeNs]);
	const value = instantFromTimeSpecMs(this.atimeMs, this[kPartialAtimeNs]);
	setOwnProperty(this, 'atimeInstant', value);
	return value;

[LiviaMedeiros]

Sure. I guess we can do the same in lazyDateFields getters.