guybedford edited a comment on issue #7569:
@alexcrichton apologies for the confusion, I made an invalid assumption that the u64 mtime value was in units of 100 nanoseconds due to a misreading of the docs, Node.js instead has 1us accuracy.
I've changed the configuration option name to
FS_TIME_PRECISION
.I also don't understand why Node is testing equality using division. Shouldn't the exact values be equal in Node? For example if Node reports a timestamp is N and it's updated to N+200us, then shouldn't the resulting timestamp afterwards be exactly N+200us?
Because Node.js rounds to microseconds, if we set a timestamp N, the timestamp that actually gets set is a Node.js-rounded N.
The other axis is a fine-grained update of time.
For now I've treated both of these axes the same - the fs time precision. Where the unit of time we update is twice the precision, and the unit of time we check for is equality under that same precision. This makes sense I think because we are effectively observing this implementation-defined rounding function.
Ready for review, further feedback welcome.
guybedford commented on issue #7569:
Assuming that the system is only reporting timestamps with rounded precision already, this means that all timestamps in play should all be appropriately rounded, right?
Good point, yes this is the issue - Node.js provides the ability to read times as
BigInt
values, but not to set them asBigInt
values. I've posted a Node.js feature request for this in https://github.com/nodejs/node/issues/50859.
alexcrichton commented on issue #7569:
Aha! Ok that makes a lot more sense now. So Node is reporting nanosecond-granularity but only supports setting at the microsecond-granularity?
guybedford commented on issue #7569:
So Node is reporting nanosecond-granularity but only supports setting at the microsecond-granularity?
Yes, that's what I'm seeing. They only support IEEE-754 values in seconds, which would only store 24 bits of precision, so I think this is actually due to floating point arithmetic rounding, but haven't verified that's definitely the reason.
guybedford edited a comment on issue #7569:
So Node is reporting nanosecond-granularity but only supports setting at the microsecond-granularity?
Yes, that's what I'm seeing. They only support IEEE-754 values in seconds, which would only store 24 digits of precision, so I think this is actually due to floating point arithmetic rounding, but haven't verified that's definitely the reason.
guybedford edited a comment on issue #7569:
So Node is reporting nanosecond-granularity but only supports setting at the microsecond-granularity?
Yes, that's what I'm seeing. They only support IEEE-754 values in seconds, which would only store 24 precision digits, so I think this is actually due to floating point arithmetic rounding, but haven't verified that's definitely the reason.
alexcrichton commented on issue #7569:
Ah I could definitely imagine that once floats are involved precision flies out the window. Thanks for putting up with my questions!
guybedford commented on issue #7569:
CI was failing due to the use of an experimental feature. I've simplified the check which should pass CI now.
Last updated: Nov 22 2024 at 16:03 UTC