Today I've started the ConcurrencyTest from commit 912c38d4c4b5da6d5b3fecaaa4cd285bcae65ebe, but it failed, because it created 20 quotes. In fact, every new request created a new daily quote, despite the fact we shouldn't do that.
After debugging a bit, I found that it consistently inserts 20 quotes with date of 2022-10-30T00:01:00+0200 into the database.
It looks like LiteDB v4 (at least!), despite storing dates in UTC, always retrieves them in the local format, and even after converting back to the UTC datetimes, they aren't working well.
For a particular example:
I have created a daily quote with a date = 2022-10-30T00:00:00Z
Say it's been inserted into the database as-is.
Now when retrieving the date for today (still 2022-10-30T00:00:00Z), LiteDB breaks. For whatever reason, it's impossible for it to retreive the data I've just inserted when queried by Query.EQ("date", BsonValue date).
All of this is probably related to DST time zone change that occurred in my time zone today (so the clocks went back from 3:00 to 2:00), and the following fact:
Today I've started the
ConcurrencyTest
from commit912c38d4c4b5da6d5b3fecaaa4cd285bcae65ebe
, but it failed, because it created 20 quotes. In fact, every new request created a new daily quote, despite the fact we shouldn't do that.After debugging a bit, I found that it consistently inserts 20 quotes with
date
of2022-10-30T00:01:00+0200
into the database.It looks like LiteDB v4 (at least!), despite storing dates in UTC, always retrieves them in the local format, and even after converting back to the UTC datetimes, they aren't working well.
For a particular example:
date = 2022-10-30T00:00:00Z
2022-10-30T00:00:00Z
), LiteDB breaks. For whatever reason, it's impossible for it to retreive the data I've just inserted when queried byQuery.EQ("date", BsonValue date)
.All of this is probably related to DST time zone change that occurred in my time zone today (so the clocks went back from 3:00 to 2:00), and the following fact:
Two UTC times mapping to one local is probably problematic, though I'm not sure if this isn't a bug in .NET
DateTime
.See also
// TODO[#163]
when fixing this.