Fix invalid date output with util.inspect

[rumkin]

Checklist

• tests and code linting passes
• a test and/or benchmark is included
• documentation is changed or added
• the commit message follows commit guidelines

Description of change

util.inspect produces default string value for invalid date instead of throwing RangeError.

[cjihrig]

Can you use assert.strictEqual() here.

[jasnell]

I'd make this simply:

assert.equal(util.inspect(new Date('')), 'Invalid Date');

there's no reason to create the second date object.

[cjihrig]

It's not a big deal because whoever lands this can fix it up but:

1. This should target the master branch, not v6.x.
2. The commit message should adhere to https://github.com/nodejs/node/blob/master/CONTRIBUTING.md#step-3-commit.

[jasnell]

just a style nit so feel free to ignore...

return ctx.stylize(Number.isNaN(value.getTime()) ?
                     value.toString() :
                     Date.prototype.toISOString.call(value),
                   'date');

... would help eliminate some minor code duplication

[jasnell]

semver-major because of the change in error handling (this eliminates a throw).

[jasnell]

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

[addaleax]

This restores the pre-v6.0.0 behaviour and probably aligns much more with user expectations than the current behaviour, so I would actually say it’s a bugfix. Otherwise, this means that no object containing an invalid Date object could be printed using console.log or in the repl.

[cjihrig]

+1 to bug fix.

[jasnell]

Works for me!

[rumkin]

@cjihrig how should I fix branch and comment now in better way?

[cjihrig]

Github doesn't allow you to target a new branch once a PR is made. However, master and v6.x are so similar, that I don't think it should matter in this case.

To change your commit message, you can run git commit --amend, then force push to the branch you used for this PR (in this case, v6.x).

[rumkin]

@cjihrig Done

[cjihrig]

LGTM once the comment about using assert.strictEqual() is addressed. I'd probably change the commit subsystem to just util too.

[jasnell]

@cjihrig ... PTAL
LGTM with the updates

Note to @rumkin : we don't get notified when new or updated commits are pushed so it can be easy to miss. Best bet is to add a comment after pushing the new commits so we get notified! :-)

[cjihrig]

LGTM. Thanks for the notification @jasnell

[rumkin]

@cjihrig @jasnell Thanks for help with my PR.

[evanlucas]

LGTM. Running CI one more time https://ci.nodejs.org/job/node-test-pull-request/2559/

[rumkin]

@cjihrig what's next? Will PR be accepted?

[addaleax]

@rumkin Thanks for commenting here again, sometimes things like this get a little lost.

This LGTM and I’m landing it now.

[addaleax]

Landed in 9c33e0e. Thanks!

[MylesBorins]

@nodejs/lts is this something we want to backport?

[addaleax]

@thealphanerd Just fyi, this was prompted by a change that came with the v8 changes in v6.0.0 and should be a no-op in the previous versions.