fs: (+/-)Infinity and NaN invalid unixtimestamp #11919

lucamaraschi · 2017-03-18T20:57:28Z

Infinity and NaN are currently considered valid input when generating a
unix time stamp but are defaulted arbitrarly to Date.now()/1000. This
PR removes this behaviour and throw an exception like all the other
invalid input types.

Checklist

make -j4 test (UNIX), or vcbuild test (Windows) passes
tests and/or benchmarks are included
documentation is changed or added
commit message follows [commit guidelines][]

Affected core subsystem(s)

fs

mscdex · 2017-03-18T21:20:21Z

doc/api/fs.md

- If the value is `NaN` or `Infinity`, the value will get converted to
-  `Date.now() / 1000`.
+- If the value is `NaN` or `Infinity` (either positive or negative), an Error is
+  going to be thrown.


Minor nit: I think 'an Error will be thrown' sounds better

Agreed. Might be better to list NaN, Infinity, or -Infinity too.

Thanks, gonna change it

ChALkeR · 2017-03-18T21:34:09Z

Not sure about this. /cc @jasnell, do we want to put this through a deprecation cycle?
Note that this changes both documented behavior and existing tests expectations.

@lucamaraschi to me it is not clear why this change should be done — that's not mentioned in this PR.

cjihrig · 2017-03-18T21:46:40Z

lib/fs.js

@@ -1164,8 +1164,8 @@ function toUnixTimestamp(time) {
  if (typeof time === 'string' && +time == time) {
    return +time;
  }
-  if (typeof time === 'number') {
-    if (!Number.isFinite(time) || time < 0) {
+  if (typeof time === 'number' && !isNaN(time) && isFinite(time)) {


isFinite() covers NaN, so I think the !isNaN(time) can be dropped.

cjihrig · 2017-03-18T21:47:03Z

test/parallel/test-fs-timestamp-parsing-error.js

+'use strict';
+const fs = require('fs');
+const assert = require('assert');
+require('../common');


Can you move this up before the other require()s.

cjihrig · 2017-03-18T21:49:27Z

doc/api/fs.md

- If the value is `NaN` or `Infinity`, the value will get converted to
-  `Date.now() / 1000`.
+- If the value is `NaN` or `Infinity` (either positive or negative), an Error is
+  going to be thrown.


Agreed. Might be better to list NaN, Infinity, or -Infinity too.

mscdex · 2017-03-18T21:50:14Z

lib/fs.js

@@ -1164,8 +1164,8 @@ function toUnixTimestamp(time) {
  if (typeof time === 'string' && +time == time) {
    return +time;
  }
-  if (typeof time === 'number') {
-    if (!Number.isFinite(time) || time < 0) {
+  if (typeof time === 'number' && !isNaN(time) && isFinite(time)) {


I think this can be simplified to just typeof time === 'number' && Number.isFinite(time)

I think Number.isFinite(time) would cover typeof time === 'number' anyway, so this is equivalent to just Number.isFinite(time).

mscdex · 2017-03-18T21:56:26Z

test/parallel/test-fs-timestamp-parsing-error.js

+});
+
+const okInputs = [1, -1, '1', '-1', Date.now()];
+okInputs.forEach((input) => assert.doesNotThrow(() =>


I think using braces and better indentation for the forEach() callback will make this look better (especially since assert methods do not return meaningful values). Example:

okInputs.forEach((input) => { assert.doesNotThrow(() => fs._toUnixTimestamp(input)); });

Agreed @mscdex, I was trying to keep it as compact as possible tho.

IMHO compactness isn't as important in tests.

addaleax · 2017-03-19T00:26:34Z

I think this makes sense, silently converting these values to the current time is not something I’d expect as a user (at least not for ±∞).

do we want to put this through a deprecation cycle?

Hm, is there any reason not to?

jasnell · 2017-03-19T00:30:59Z

I'm not convinced this behavior was intentional. It could be viewed as a bug fix and it is in a _-prefixed method. Unless we can find direct uses that would be problematic, I don't think a deprecation cycle should be necessary.

TimothyGu · 2017-03-19T01:15:58Z

test/parallel/test-fs-timestamp-parsing-error.js

+const fs = require('fs');
+const assert = require('assert');
+
+[Number.POSITIVE_INFINITY, Number.NEGATIVE_INFINITY, NaN].forEach((input) => {


nit: any reasons the shorter form -Infinity and Infinity are not used?

cjihrig

LGTM once @not-an-aardvark's nit is addressed.

mcollina

LGTM. I don't think it was intentional in the first place.

cjihrig · 2017-03-20T17:21:26Z

@lucamaraschi this needs a rebase. Could you squash the commits while you're at it.

Infinity and NaN are currently considered valid input when generating a unix time stamp but are defaulted arbitrarly to Date.now()/1000. This PR removes this behaviour and throw an exception like all the other invalid input types.

cjihrig · 2017-03-21T23:17:28Z

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

Infinity and NaN are currently considered valid input when generating a unix time stamp but are defaulted arbitrarly to Date.now()/1000. This PR removes this behaviour and throw an exception like all the other invalid input types. PR-URL: #11919 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]>

jasnell · 2017-03-22T05:42:19Z

Landed in eed87b1

nodejs-github-bot added the fs Issues and PRs related to the fs subsystem / file system. label Mar 18, 2017

mscdex added the semver-major PRs that contain breaking changes and should be released in the next major version. label Mar 18, 2017

mscdex reviewed Mar 18, 2017

View reviewed changes

cjihrig requested changes Mar 18, 2017

View reviewed changes

mscdex reviewed Mar 18, 2017

View reviewed changes

TimothyGu reviewed Mar 19, 2017

View reviewed changes

cjihrig approved these changes Mar 19, 2017

View reviewed changes

mcollina approved these changes Mar 20, 2017

View reviewed changes

jasnell approved these changes Mar 20, 2017

View reviewed changes

lucamaraschi force-pushed the fs-fix-unixtimestamp-ctor-validation branch from e5718ba to 3588f6a Compare March 20, 2017 22:10

fs: (+/-)Infinity and NaN invalid unixtimestamp

1716ef5

Infinity and NaN are currently considered valid input when generating a unix time stamp but are defaulted arbitrarly to Date.now()/1000. This PR removes this behaviour and throw an exception like all the other invalid input types.

lucamaraschi force-pushed the fs-fix-unixtimestamp-ctor-validation branch from 3588f6a to 1716ef5 Compare March 20, 2017 22:10

jasnell closed this Mar 22, 2017

jasnell mentioned this pull request Apr 4, 2017

8.0.0 Release Proposal #12220

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fs: (+/-)Infinity and NaN invalid unixtimestamp #11919

fs: (+/-)Infinity and NaN invalid unixtimestamp #11919

lucamaraschi commented Mar 18, 2017

mscdex Mar 18, 2017

cjihrig Mar 18, 2017

lucamaraschi Mar 18, 2017

ChALkeR commented Mar 18, 2017 •

edited

Loading

cjihrig Mar 18, 2017

cjihrig Mar 18, 2017

cjihrig Mar 18, 2017

mscdex Mar 18, 2017

not-an-aardvark Mar 18, 2017

mscdex Mar 18, 2017 •

edited

Loading

lucamaraschi Mar 18, 2017

mscdex Mar 18, 2017

addaleax commented Mar 19, 2017

jasnell commented Mar 19, 2017

TimothyGu Mar 19, 2017

cjihrig left a comment

mcollina left a comment

cjihrig commented Mar 20, 2017

cjihrig commented Mar 21, 2017

jasnell commented Mar 22, 2017

fs: (+/-)Infinity and NaN invalid unixtimestamp #11919

fs: (+/-)Infinity and NaN invalid unixtimestamp #11919

Conversation

lucamaraschi commented Mar 18, 2017

Checklist

Affected core subsystem(s)

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ChALkeR commented Mar 18, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mscdex Mar 18, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

addaleax commented Mar 19, 2017

jasnell commented Mar 19, 2017

Choose a reason for hiding this comment

cjihrig left a comment

Choose a reason for hiding this comment

mcollina left a comment

Choose a reason for hiding this comment

cjihrig commented Mar 20, 2017

cjihrig commented Mar 21, 2017

jasnell commented Mar 22, 2017

ChALkeR commented Mar 18, 2017 •

edited

Loading

mscdex Mar 18, 2017 •

edited

Loading