Posting this for the next person that comes across this issue.
Our dotnet backend was treating the DateTime object kind as local
and the abp.timing.timeZoneInfo.iana was set to Etc/UTC
This missmatch seems to have caused the issue.
Adding Clock.Provider = ClockProviders.Utc; to the PreInitialize() method of our WebCoreModule.cs file was the fix to match Angular App and API.
@ismcagdas do you know why the abp.timing.timeZoneInfo would have been set to Etc/UTC?
Ok, from what I can see I needed to set the Clock Provider in PreInitialize method of the Core web module.
That then set the "kind" portion of the datetime object in the backend and it's now behaving as expected.
I'm not sure why the angular client to Etc/UTC as a default?
Not only that, the "Date" portion of the DateTime object is also incorrect.
2/1/1970 in first screenshot - where I picked 2/2/1970 using the ngx-datepicker angular component (incorrect)
10/10/1970 in second screenshot - I picked 10/10/1970 using the component (correct)
Hi,
For example, i pick 10th October 1970 - Saved in database as "1970-10-10 00:00:00.0000000" - Correct
I pick 2nd February 1970 - Saved in database as "1970-02-01 23:00:00.0000000" - Incorrect - 1 hour off
Hi , I've seen this bug replicated on another project also (v9.0.1) specifically around the dates 19 Feb 1968 -> 31st Oct 1971.
The bug doesn't manifest itself on later dates.
Hi @ismcagdas, would it make sense that this bug is only affecting some date ranges if the clock provider was incorrectly set? It doesn't make sense to me.
I set the clock provider in webcoremodule.cs in pre initialize method using this line of code, is this the correct way to do it?
Clock.Provider = ClockProviders.Utc;