DateTime storing the wrong date time when saved outside of BST
If you save a DateTime property editor for a date that spans across day light savings time it looks to store the wrong value in the database.
For example; I live in the UK and if today I save a date 08/03/2022 18:00:00, I can see that in the database as 2022-03-08 18:00:00.000 (assuming UTC) which is correct.
If I then save the date time as 06/04/2022 18:00:00, I can see the database stores it as 2022-04-06 18:00:00.000 (assuming UTC) which is incorrect. As daylight saving kicks in 27th March, I would have expected to see 2022-04-06 17:00:00.000 in the database, as we'll be in BST so the time will be UTC + 1hour.
Has anyone seen this issue before and have any solutions?
Looks like this is a problem with how the editor works. The code for which is here.
It looks like the issue stems from the fact that the system detects the offset based on the current date, not the input date.
// check whether a server time offset is needed
if (Umbraco.Sys.ServerVariables.application.serverTimeOffset !== undefined) {
// Will return something like 120
var serverOffset = Umbraco.Sys.ServerVariables.application.serverTimeOffset;
// Will return something like -120
var localOffset = new Date().getTimezoneOffset();
// If these aren't equal then offsetting is needed
// note the minus in front of serverOffset needed
// because C# and javascript return the inverse offset
$scope.serverTimeNeedsOffsetting = (-serverOffset !== localOffset);
}
Utilizing the previous example, if i run the following code through currently i get
new Date().getTimezoneOffset()
0
whereas, if i was to pass the following, we get the correct offset that would require applying.
new Date(2022, 4, 6).getTimezoneOffset()
-60
To overcome this, you will probably need to hook into the ContentService.Saving Notification and manipulate the datetime value to be correct prior to it being committed to the DB.
Sorry - I must have forgotten to list my solution here! We effectively created a new property editor that took care of the timezone within the client (using MomentJS which isn't advised now).
The idea being that the data being sent to and received from Umbraco will be in UTC then it's up to the client to work out what time it is in the user's world.
If you would like to see what we ended up with, here's a GitHub Gist with the package in.
DateTime storing the wrong date time when saved outside of BST
If you save a DateTime property editor for a date that spans across day light savings time it looks to store the wrong value in the database.
For example; I live in the UK and if today I save a date 08/03/2022 18:00:00, I can see that in the database as 2022-03-08 18:00:00.000 (assuming UTC) which is correct.
If I then save the date time as 06/04/2022 18:00:00, I can see the database stores it as 2022-04-06 18:00:00.000 (assuming UTC) which is incorrect. As daylight saving kicks in 27th March, I would have expected to see 2022-04-06 17:00:00.000 in the database, as we'll be in BST so the time will be UTC + 1hour.
Has anyone seen this issue before and have any solutions?
Hi Richard,
Did you ever get an answer to this or resolve it, we are having the same issue.
Hi Roberto,
Looks like this is a problem with how the editor works. The code for which is here.
It looks like the issue stems from the fact that the system detects the offset based on the current date, not the input date.
Utilizing the previous example, if i run the following code through currently i get
whereas, if i was to pass the following, we get the correct offset that would require applying.
To overcome this, you will probably need to hook into the ContentService.Saving Notification and manipulate the datetime value to be correct prior to it being committed to the DB.
Sorry - I must have forgotten to list my solution here! We effectively created a new property editor that took care of the timezone within the client (using MomentJS which isn't advised now).
The idea being that the data being sent to and received from Umbraco will be in UTC then it's up to the client to work out what time it is in the user's world.
If you would like to see what we ended up with, here's a GitHub Gist with the package in.
Thanks both, will digest this!
is working on a reply...