DateTime storing problem

[podkolzzzin]

As for me the line "Fail" shouldn't be ever printed.
After a bit of debugging I understood that it's because you store DateTime with the less precision.
It would be interesting for me to read why you have done like this? As for me DateTime is only 8 bytes, and you have probably saved 1 or 2, or even lose something using string.

The code is:

       DateTime dt = DateTime.Now;
        var testId = ObjectId.NewObjectId();
        using (LiteDatabase db = new LiteDatabase("file.db"))
        {
            var doc = new BsonDocument();
            doc["t"] = dt;
            doc["_id"] = testId;
            db.GetCollection("Test").Insert(doc);
        }

        using (LiteDatabase db = new LiteDatabase("file.db"))
        {
            var doc = new BsonDocument();
            doc["t"] = dt;
            var dt2 = db.GetCollection("Test").FindById(testId)["t"].AsDateTime;
            if (dt != dt2)
            {
                Console.WriteLine("Fail");
            }
        }

[mbdavid]

Hi @podkolzzzin, LiteDB stores DateTime using BitConverter. Did you check if date diff are not about timezone?

[henon]

Yep, I can confirm that. LiteDB stores DateTime with millisecond precision and truncates the nanoseconds. I think the reason is to be compatible to JSON/BSON. That is why I chose to save the Ticks instead and convert them back to DateTime.

[podkolzzzin]

There are perfect methods ToBinary/FromBinary in DateTime structure, you could probably use them

[mbdavid]

Hi @henon, LiteDB store in ticks.

    public void Write(DateTime value)
    {
        this.Write(value.ToUniversalTime().Ticks);
    }

I didnt know about ToBinary/FromBinary methods. It's not possible change now because all datafiles will be affected.

[dropsonic]

@mbdavid I faced the same issue.
Original DateTime (Ticks property): 637310234309996491
Ticks property after I saved and read the value from LiteDB: 637310234309990000

[lbnascimento]

@dropsonic This is a limitation in the BSON specification, which LiteDB implements: dates are stores as UTC milliseconds since the Unix epoch.

If you want to keep all the precision from DateTime, you should store Ticks.

[dropsonic]

It seems inconvenient because I'd like to use auto-serialization of POCO.
According to the answer above, LiteDB stores ticks so it is quite strange that this issue exists.

[martin-slater]

Just a me to to this as I have been bitten by it and now need to add a hack somewhere else to work around it. It is a surprising result and just wrong. It would seem you could add a pragma to allow users to enable correct behaviour (serializing and deserializing a DateTime will compare equals).