U4-10937 - Datepicker on Info tab and dates on audit trail do not work if server time needs offsetting

Created by Sebastiaan Janssen 06 Feb 2018, 18:08:04 Updated by Jacob Midtgaard-Olesen 23 Apr 2018, 13:53:54

Tags: Unscheduled

When the server time and the user's local time don't correspond, the date picker for scheduled publishing doesn't work, nor does the audit trail show dates.

== Update: A temporary fix is available using the two js files in this comment: http://issues.umbraco.org/issue/U4-10937#comment=67-44430 ==

7 Attachments

Download U4-10937.mp4

Download umbraco.services.js

Download umbraco.services.js

Download umbraco.directives.js

Comments

Sebastiaan Janssen 06 Feb 2018, 18:11:30

Workaround: in ~/umbraco/Js/umbraco.service.js replace line 9323:

dateVal = dateHelper.convertToLocalMomentTime(date, serverOffset);

with

dateVal = this.convertToLocalMomentTime(date, serverOffset);

The problem is that you can't use a method on a factory that you're still defining.


Sebastiaan Janssen 06 Feb 2018, 18:17:11

PR: https://github.com/umbraco/Umbraco-CMS/pull/2429


Sebastiaan Janssen 06 Feb 2018, 20:22:26

Note, the workaround above resolves the javascript error, but the timezone difference is calculated incorrectly at the moment. Looking into it.


Shannon Deminick 06 Feb 2018, 23:32:40

Here's part of the problem:

  • A call is made to formatDatesToLocal on load (AFAIK) which formats server dates to local dates, this needs testing to make sure it's correct but the logic seems right
  • Then a user will schedule a publishing date. The user is selecting their own local date/time! ... but then a call to formatDatesToLocal is made again which is attempting to convert the user's own local date/time (non server time) to the user's local date/time ... which is calculating something that doesn't need to be done

The thing to remember is that the date/time's displayed to the user are NOT the values that are persisted to the model that is sent back to the server, however it seems that the date picker is binding to the values that are being sent back to the server. For example, the scope.node.releaseDate is currently being updated to the date/time that the user is modifying but that is incorrect, the value that the user is modifying is their own local date/time, this then needs to be converted to the server time and stored against scope.node.releaseDate

The new Info tab no longer performs the necessary operations that the date picker did. The date picker was the thing that managed this before for setting scheduled published date/times. So the logic for these new date/time pickers for this tab need to adhere to the same principals that the date picker does. For example, here's the code for the date picker that sets the model value that is sent to the server: https://github.com/umbraco/Umbraco-CMS/blob/dev-v7.8/src/Umbraco.Web.UI.Client/src/views/propertyeditors/datepicker/datepicker.controller.js#L66

So it seems to me that the Info tab date pickers are binding directly to the model which is not how it is supposed to be.


Shannon Deminick 06 Feb 2018, 23:34:16

To test this without worrying about setting up different servers in different timezones :P ... you can adjust the server offset time returned by Umbraco to anything you want, you can do that in the BackOfficeServerVariables class and change the serverTimeOffset to anything you want


Shannon Deminick 07 Feb 2018, 01:53:39

I've pushed a changes which should fix this, however some testing will be needed.

For the audit trail fix, it seems that when the date is formatted as Roundtrip UTC (ISO_8601) which is the default returned from the server, when parsing with moment(date), it will automatically convert to local and then we were converting to local again, so we detect this format now and load it with moment.utc(date) so it's not mucked with and then do the conversion.

This seems to work on my tests both locally and on Cloud but testing needs to be done for:

  • The scheduled publishing stuff
  • The audit trail date/times
  • The date picker property editor - for both when offset is enabled and disabled


Sebastiaan Janssen 07 Feb 2018, 07:32:03

It's almost correct now, except the scheduled publishing datepicker is still an hour of the actual picked time. See video for a better explanation.


Sebastiaan Janssen 07 Feb 2018, 07:34:32

Maybe this is intentional, we used to have this thing saying: it's scheduled for your local time, the time on the server would be server time.

However, then the logic is off by 2 hours, for me since the server is on UTC, 1 hour earlier than my local time. So in the video I would then expect it to show things are going to happen at 7, instead of 9 since it is currently 8 over here.


Shannon Deminick 07 Feb 2018, 07:42:49

Everything should be displayed to YOU in your own local time for the audit trail and for the sheduled publishing dates, you should not see the server date/times


Shannon Deminick 07 Feb 2018, 07:44:25

Just to be sure you rebuilt the client files right? but yes, i can see in the video that your picked date changes, this shouldn't be the case, the picked date should stay the date your chose obviously :P


Sebastiaan Janssen 07 Feb 2018, 08:25:37

Yep, all rebuilt, the audit trail is correct now!


Sebastiaan Janssen 07 Feb 2018, 08:31:57

For people following along, the fix Shannon added is in the attached file. It almost works now and at least it's visible what you're doing and you can work around it by fudging the time a little (the time shown after the picker closes is the actual time when the scheduled publish will happen, see screenshot, 9:36 in this case).


Sebastiaan Janssen 07 Feb 2018, 14:54:22

The final workaround, for people landing here, is to drop the attached two files in the ~/umbraco/Js/ folder.


Shannon Deminick 08 Feb 2018, 05:02:34

@warren.buckley Just want to make sure that you guys tested the normal date picker property editor too with both offsetting time enabled and disabled? (i.e. from the pre-values)


Warren Buckley 08 Feb 2018, 08:30:49

Yes just tested it with Seb now @Shandem and it works all fine


Priority: Major

Type: Bug

State: Fixed

Assignee:

Difficulty: Normal

Category:

Backwards Compatible: True

Fix Submitted:

Affected versions: 7.8.0

Due in version: 7.8.1

Sprint: Sprint 78

Story Points: 1

Cycle: 8