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

[lucamaraschi]

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]

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

[cjihrig]

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

[lucamaraschi]

Thanks, gonna change it

[ChALkeR]

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]

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

[cjihrig]

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

[cjihrig]

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

[mscdex]

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

[not-an-aardvark]

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

[mscdex]

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));});

[lucamaraschi]

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

[mscdex]

IMHO compactness isn't as important in tests.

[addaleax]

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]

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]

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]

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

[cjihrig]

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

[jasnell]

Landed in eed87b1