Scheduling displays "Invalid date" in Umbraco 12.3.1

[matteus-hemstrom-nltg]

Which Umbraco version are you using? (Please write the exact version, example: 10.1.0)

12.3.1

Bug summary

When upgrading to Umbraco 12.3.0 we found that the scheduling function stopped working. We have since then upgraded to 12.3.1 hoping that it would resolve our issue as it is addressed in the release note "Scheduling Posts gives invalid date in Umbraco 12.3". Unfortunately, we still have an issue with the scheduling modal. The date picker still show "invalid date" in the scheduling modal.

Specifics

Note that this seems to be a frontend issue only, because if one proceed to schedule the document with "invalid date", the document will still be scheduled and published according to the date and time that was selected.

I have tracked the issue down to the following code:

• formatDatesToLocal in schedule.controller.js, see https://github.com/umbraco/Umbraco-CMS/blob/v12/dev/src/Umbraco.Web.UI.Client/src/views/content/overlays/schedule.controller.js#L279-L286
• getLocalDate and convertToLocalMomentTime in util.service.js, see https://github.com/umbraco/Umbraco-CMS/blob/v12/dev/src/Umbraco.Web.UI.Client/src/common/services/util.service.js#L78-L117

The date returned from convertToLocalMomentTime is not valid (e.g. 'Nov 14th 2023, 13:08-00:00').

I have also found it works if I modify Umbraco.Sys.ServerVariables.application.serverTimeOffset so that serverTimeNeedsOffsetting is evaluated to false. However, I'm not sure if that will cause timezone issues when publishing. This means that you need to have a different server time zone than your browser to reproduce the issue. The issue is therefore likely not reproducible locally because the server and browser will use the same time zone.

Steps to reproduce

I think you diff in server timezone and browser timezone to trigger the issue, then:

1. Open the scheduling modal by clicking "Schedule..."
2. Select a date using the date picker
3. Notice that the date picker button now shows "Invalid date"

Expected result / actual result

The selected dates should be visible in the scheduling modal.

[github-actions]

Hi there @matteus-hemstrom-nltg!

Firstly, a big thank you for raising this issue. Every piece of feedback we receive helps us to make Umbraco better.

We really appreciate your patience while we wait for our team to have a look at this but we wanted to let you know that we see this and share with you the plan for what comes next.

• We'll assess whether this issue relates to something that has already been fixed in a later version of the release that it has been raised for.
• If it's a bug, is it related to a release that we are actively supporting or is it related to a release that's in the end-of-life or security-only phase?
• We'll replicate the issue to ensure that the problem is as described.
• We'll decide whether the behavior is an issue or if the behavior is intended.

We wish we could work with everyone directly and assess your issue immediately but we're in the fortunate position of having lots of contributions to work with and only a few humans who are able to do it. We are making progress though and in the meantime, we will keep you in the loop and let you know when we have any questions.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[bergmania]

Hi @matteus-hemstrom-nltg

What version did you update from? That could make it easier to find the root cause?

[matteus-hemstrom-nltg]

Hi @matteus-hemstrom-nltg

What version did you update from? That could make it easier to find the root cause?

We think that it was working on 12.2.0.

[andr317c]

Hey! Thanks for reporting this issue, I was able to reproduce it on versions 12.3.2, 12.3.1, and 12.3.0. I followed the reproduction steps by changing my browser timezone to a different one than the server, which led me to:

I tested it on version 12.2.0 and it worked without any issues, so the issue occurred between 12.2.0 and 12.3.0
I will mark this issue as a sprint candidate

[andr317c]

The issue also occurs on version 13.0.0-rc2

[rongrisnich]

Facing the same issue on Umbraco Cloud with 12.3.1.

[andr317c]

Hey @bjarnef
This issue seems to be caused by this PR #13500. Could you maybe have a look into it? 😄

[matteus-hemstrom-nltg]

Hey @bjarnef This issue seems to be caused by this PR #13500. Could you maybe have a look into it? 😄

Just looking at that PR, it seems like parsingFormat should be passed to convertToLocalMomentTime instead of format:
https://github.com/umbraco/Umbraco-CMS/blob/contrib/src/Umbraco.Web.UI.Client/src/common/services/util.service.js#L111

[bjarnef]

@matteus-hemstrom-nltg no, I don't think that is correct.

Before it didn't sent in format to this.
https://github.com/umbraco/Umbraco-CMS/pull/13500/files#diff-277b13396c90722385a98d599dbfea84855ff088949d00d4b5d14259208ed034R111

which used the format YYYY-MM-DDTHH:mm:ss by default. Parsing format is different YYYY-MM-DD HH:mm:ss and used when one know a specific format of a datetime and want to convert that.

I think the issue it that where getLocalDate() is called different format is passed in, e.g. LLL or MMM Do YYYY, HH:mm", but the format in moment is used how the date should be formatted, which is also used in the end.
https://github.com/umbraco/Umbraco-CMS/pull/13500/files#diff-277b13396c90722385a98d599dbfea84855ff088949d00d4b5d14259208ed034R115

[bjarnef]

I don't think format should be passed in here:
https://github.com/umbraco/Umbraco-CMS/pull/13500/files#diff-277b13396c90722385a98d599dbfea84855ff088949d00d4b5d14259208ed034R111

at least the format before was YYYY-MM-DDTHH:mm:ss.

I think convertToLocalMomentTime() could have a forth parameter parsingFormat = "YYYY-MM-DD HH:mm:ss" which can eventually could be used here.
https://github.com/umbraco/Umbraco-CMS/pull/13500/files#diff-277b13396c90722385a98d599dbfea84855ff088949d00d4b5d14259208ed034R96

[bjarnef]

@andr317c any change you can test with this PR? #15223

[andr317c]

Hey @bjarnef
I just tested your PR and it works! I'll go ahead and merge it in contrib 😄

And I'll close this issue.