Skip to content

Setting null prototype to Date object results error #25145

Description

@antsmartian
  • Version: 10.0.0
  • Platform: Mac

Found this, when working on this #25144

Running the below code:

console.log(Object.setPrototypeOf(new Date(), null))

results in error:

util.js:599
        if (Number.isNaN(value.getTime()))
                               ^

TypeError: value.getTime is not a function
    at formatValue (util.js:599:32)
    at inspect (util.js:336:10)
    at Object.formatWithOptions (util.js:190:12)
    at Console.(anonymous function) (console.js:186:15)
    at Console.log (console.js:197:31)
    at Object.<anonymous> (/Users/anto/programs/node/node-hack/date.js:1:71)
    at Module._compile (internal/modules/cjs/loader.js:678:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:689:10)
    at Module.load (internal/modules/cjs/loader.js:589:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:528:12)

The same code works on master though.

cc @BridgeAR

Activity

  1. devsnek commented on Dec 20, 2018

    @devsnek
    Member

    we should be using Date.prototype.getTime.call(value), like we do with regex etc

  2. added
    utilIssues and PRs related to the built-in util module.
    on Dec 20, 2018
  3. BridgeAR commented on Dec 20, 2018

    @BridgeAR
    Member

    This could potentially be backported but I don't think we need an issue for it. There are lots of cases like that in 10 and it's not limited to dates.
    Please feel free to reopen if you think this should stay open.

  4. antsmartian commented on Dec 20, 2018

    @antsmartian
    ContributorAuthor

    Is there any other place where we are tracking the other issues (as you had mentioned). Or we can add a backport label on the PR which already in master, which fixes the issue?

  5. BridgeAR commented on Dec 20, 2018

    @BridgeAR
    Member

    No, there's no tracking issue. Backports are done automatically but some of these changes might have been done in a semver-major commit or might not yet been backported due to lots of conflicts. In the latter case the label will normally be applied by the person who found that there are to many conflicts to fix those easily for a release and we have to do those manually.

    You could check where this change was done by looking at git blame and then checking the PR in which those changes have been made.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    utilIssues and PRs related to the built-in util module.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions