[SERVER-14891] Shell will create invalid dates and then persist them Created: 13/Aug/14  Updated: 10/May/22

Status: Backlog
Project: Core Server
Component/s: Shell
Affects Version/s: 2.7.3
Fix Version/s: None

Type: Bug Priority: Minor - P4
Reporter: Alvin Richards (Inactive) Assignee: DO NOT USE - Backlog - Platform Team
Resolution: Unresolved Votes: 0
Labels: 28qa, move-sa, neweng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-960 Dates before epoch not retrieved corr... Closed
Backwards Compatibility: Minor Change
Operating System: ALL
Steps To Reproduce:

In the shell

> var foo
> fred = new Date(foo)
ISODate("0NaN-NaN-NaNTNaN:NaN:NaNZ")
> db.boo.insert({mydate: fred})
WriteResult({ "nInserted" : 1 })
> db.boo.find()
{ "_id" : ObjectId("53ebe8ee637817446a874584"), "mydate" : ISODate("0NaN-NaN-NaNTNaN:NaN:NaNZ") }

Participants:

 Description   

Problem:
Its possible for the Shell to create an invalid date, persist it and then cause other drivers to fail, python example

  File "/usr/lib/python2.6/site-packages/pymongo-2.7.1-py2.6-linux-x86_64.egg/bson/__init__.py", line 234, in _get_date
    dt = EPOCH_NAIVE + datetime.timedelta(seconds=seconds)
InvalidBSON: normalized days too large to fit in a C int

An octal dump of the .bson file from mongodump reveals

od -xa dump/test/boo.bson 
0000000    0026    0000    5f07    6469    5300    edeb    12d6    bc16
          & nul nul nul bel   _   i   d nul   S   k   m   V dc2 syn   <
0000020    a63b    f008    097e    796d    6164    6574    0000    0000
          ;   &  bs   p   ~  ht   m   y   d   a   t   e nul nul nul nul
0000040    0000    0000    0080
        nul nul nul nul nul nul



 Comments   
Comment by Steven Vannelli [ 10/May/22 ]

Moving this ticket to the Backlog and removing the "Backlog" fixVersion as per our latest policy for using fixVersions.

Comment by Matt Kangas [ 28/Aug/14 ]

Even simpler reproduction:

> var wilma = new Date(NaN)
> wilma
ISODate("0NaN-NaN-NaNTNaN:NaN:NaNZ")
> wilma.valueOf()
NaN

Also:

> var barney = new Date(undefined)
> barney
ISODate("0NaN-NaN-NaNTNaN:NaN:NaNZ")
> barney.valueOf()
NaN

It's not unique to our shell; both Firefox and Chrome exhibit the same behavior. JavaScript simply permits "NaN" Dates, but we should prohibit them from being serialized to (invalid) BSON.

This will be a minor backwards incompatibility for the shell.

Comment by J Rassi [ 13/Aug/14 ]

behackett: right, of course it's signed, my mistake.

Comment by Bernie Hackett [ 13/Aug/14 ]

That can't be right. How can you represent time before the epoch with an unsigned? Also, the spec defines it an int64, not uint64.

UTC datetime - The int64 is UTC milliseconds since the Unix epoch.

Comment by J Rassi [ 13/Aug/14 ]

I believe neither the shell nor the server is misbehaving here. The BSON spec defines the "UTC datetime" type as an unsigned 64-bit integer representing the number of milliseconds since the epoch. Any 64-bit value for this type is valid for storage and retrieval.

Generated at Thu Feb 08 03:36:17 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.