Repository navigation
regression: fs.utimes/futimes for dates before unix epoch #14017
Description
As of Node v4, fs.utimes and fs.utimes are truncating the atime and mtime values to a positive integer.
This is incorrect, and makes it impossible to set atime and mtime values before 1970-01-01T00:00:00.000Z without creating a Date object.
It looks like this is the culprit:
function toUnixTimestamp(time) {
// eslint-disable-next-line eqeqeq
if (typeof time === 'string' && +time == time) {
return +time;
}
if (Number.isFinite(time)) {
if (time < 0) {
return Date.now() / 1000;
Activity
MylesBorins commentedon Jul 3, 2017
@isaacs is this recently introduced in v4.8.3? Is there an earlier version of v4.x where this is not happening?
TimothyGu commentedon Jul 4, 2017
It was introduced in #2387 (specifically in #2387 (comment)), backported to version 4.1.0. In other words, only version 4.0.0 in the v4.x branch is not affected by the bug.
gireeshpunathil commentedon Apr 28, 2018
Was this fixed through #15680 ? Given 4.x entering EOL, this looks like a close candidate?
/cc @refack @lpinca
BridgeAR commentedon Apr 28, 2018
@gireeshpunathil that was a doc update about Infinity and NaN. Are you certain you referenced the correct PR? #15680 is independent from this issue as far as I can tell.
gireeshpunathil commentedon Apr 28, 2018
probably not - I was just following the linked references.
kevintab95 commentedon Oct 4, 2018
An observation: On specifying a negative timestamp as a string for values before 1970-01-01T00:00:00.000Z the atime and utime were modified correctly (https://nodejs.org/api/fs.html#fs_fs_utimes_path_atime_mtime_callback).
Should we document this or figure out a way to fix it? Thanks.
Fishrock123 commentedon Jan 24, 2019
I also cannot reproduce. The example above works fine on node
masterso I guess it was fixed some time since 4.x. This won't be fixed in 4.x, of course, since that branch has been sunset.