-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DateTime storing problem #420
Comments
Hi @podkolzzzin, LiteDB stores DateTime using BitConverter. Did you check if date diff are not about timezone? |
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. |
There are perfect methods ToBinary/FromBinary in DateTime structure, you could probably use them |
Hi @henon, LiteDB store in ticks.
I didnt know about ToBinary/FromBinary methods. It's not possible change now because all datafiles will be affected. |
@mbdavid I faced the same issue. |
@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 |
It seems inconvenient because I'd like to use auto-serialization of POCO. |
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). |
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:
The text was updated successfully, but these errors were encountered: