DateTime strange UTC(?) offsetting between inserting and selecting
See original GitHub issueI have such data model:
public class MyObject
{
[BsonId]
public long Id { get; set; }
[JsonConverter(typeof(Iso8601DateTimeConverter))]
public DateTime? DueTo { get; set; }
}
This DateTimeConverter, is:
public class Iso8601DateTimeConverter : IsoDateTimeConverter
{
public override void WriteJson(JsonWriter writer, object value, JsonSerializer serializer)
{
var dateTime = (DateTime)value;
serializer.Serialize(writer, dateTime.ToString("yyyy-MM-ddTHH:mm:ssZ"));
}
}
When data comes from API, it’s like in below example:
{
"Id": 98,
"DueTo": "2014-01-01T06:00:00Z"
}
From code perspective, DueTo field is 2014-01-01 at 06:00 AM.
But when I’m inserting/upserting data into LiteDB, it’s beeing converted into 2014-01-01 at 07:00 AM - data format is not the problem here, but the strange offset.
The question is why? When I’ve looked into my_db_file.db, inside it’s 2014-01-01 07:00:00.000 string.
What can I do, to ommit data inconsistency between inserting and selecting DateTime in LiteDB? Is there any special BSON attribute to be set?
Issue Analytics
- State:
- Created 6 years ago
- Comments:15 (7 by maintainers)
Top Results From Across the Web
Inserting a UTC offset datetime into SQL changes the time
I believe we should be storing datetime with UTC offset, but cannot figure out why this just started happening after the DST change...
Read more >4 Common Datetime Mistakes in C# And How to Avoid Them
In C#, Datetime is one of the easiest things to get wrong. ... UTC offset, enabling you to reconstruct the UTC date from...
Read more >Why is GETUTCDATE earlier than SYSDATETIMEOFFSET?
First, DATETIME is only accurate / granular to every 3 milliseconds. Hence, converting from a more precise datatype such as DATETIMEOFFSET or ...
Read more >SQL Server datetimeoffset for Time Zones
In this article we look at the datetimeoffset data type in SQL Server and how this can be used to determine dates for...
Read more >How to Get SQL Server Dates and Times Horribly Wrong
The SYSUTCDATETIME function returns the same data, but as a UTC value. The SYSDATETIMEOFFSET function returns the current date and time as a ......
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Perhaps instead, store the Kind as well? I just got bitten by this myself. In my application the dates are all Kind=UTC. I was trying to compare Newtonsoft JSON deserialized event message data by value with what I was getting back from LiteDB, and they were not matching up like I expected.
Hi @Szymaniuk, yes. By default, BSON deserialization keeps DateTime as Kind=Local to be compatible. If you want work with UTC, you must define in connection string (or if you use LiteEngine you can specify in ctor).