The date picker is empty after save/publish for users with locales not matching the angular locale files

[lars-erik]

The date picker is empty after save/publish for users with locales not matching the angular locale files. (Probably affects more than the date picker)

Reproduction

(done with Umbraco 7.13.1)

• Create a data type using the property editor Umbraco.DateTime.

• Keep the default format DD.MM.YYYY HH:mm (dunno if it affects anything)

• Keep offset on (dunno if it affects anything)

• Use the data type for a property

• Create a user with Norwegian locale

• Log into the backoffice

• Create doc. with the date picker

• Select a date

• Save & Publish

The date should now be blank, although stored. (save / publish now clears the date)
The date is back if the backoffice and/or content is reloaded.

Bug summary

The Norwegian user locale is nb-NO. The angular-locale_nb-NO.js file is attempted loaded, but does not exist, since only angular-locale_no.js is bundled with angular 1.1.5.
This leads to the behavior described above.

Expected result

Correct locale file loaded and dates shown after save/publish.

Actual result

No locale file loaded and date blank after save/publish.

---

Workaround

I work around it for now by copying the file on build:

<Target Name="EnsureNorwegianLocaleFile" AfterTargets="CopyUmbracoFilesToWebRoot">
    <Copy SourceFiles=".\umbraco\lib\angular\1.1.5\i18n\angular-locale_no.js" DestinationFiles=".\umbraco\lib\angular\1.1.5\i18n\angular-locale_nb-NO.js" Condition="!Exists('.\umbraco\lib\i18n\angular-locale_nb-NO.js')"/>
</Target>

Suggested fix

Copy the file manually in Umbraco.Web.UI.Client since angular 1.1.5 won't be upgraded nor probably ever contain the file angular-locale_nb-NO.js. :)

[lars-erik]

To make it better, this doesn't work on vanilla Azure Apps, so I'll update when I find a fix that works "all over".

[stevemegson]

Is this definitely being triggered by the user's locale? It looks similar to #6102, which is triggered by the date picker's format being set to something other than YYYY-MM-DD HH:mm.

[nul800sebastiaan]

Hey @lars-erik ! I think it might be time for an upgrade. I can't reproduce in 7.15.2 (coming up on Tuesday).

And in fact that language file is there:

We updated a lot in 7.15 so I think the Norwegian language might have gotten included there (if that is even the reason).

[lars-erik]

@nul800sebastiaan As mentioned in the OP, the _no.js file does no good. Users with Norwegian locale attempt to load _nb-NO.js.
Also, the solution fails if you modify the timezone on an Azure App Service.
So it works to have the _nb-NO.js file locally, but when deployed to a webservice with WEBSITE_TIME_ZONE set to W. Europe Standard Time it starts breaking down again, and to make matters better, the "slide time" option makes the time increase one (x) hours each time a node is saved/published again. 🤣

I'm not sure whether I can squeeze in any time to debug more ASAP, but the component definitely need some thorough QA before any patch.

@stevemegson We didn't modify the default format, so at best this is supplemental or related rather than duplicate.

[lars-erik]

Bah. Looks like you're right. We do have another format. I was positive that had to be some default setting, but I'm sure we have tampered with it. Crossing fingers for 15.2, then.

[lars-erik]

Although it doesn't work with default format either on 7.15.1. It goes blank on save/publish, even with the nb-NO.js file loaded. (Something tells me that actually doesn't have to do with anything)
It does not go blank on blur like #6102

[lars-erik]

Can currently reproduce on 7.15.1 on Azure WebApps, but can't reproduce locally (iisexpress). (!)
It does not matter what I put in the format settings for the datatype. Fails with blank as well.
It surely must be related to timzone on the server... (?)

[stevemegson]

It does sound like a time zone issue rather than a format issue. Can you see what value the server is returning in /umbraco/backoffice/UmbracoApi/Content/GetById?id=xxxx? That should tell us whether the value is being discarded on server, or the correct value is being sent to the client and then discarded there.

[lars-erik]

I just discovered the place in the property editor controller where it fails. Took a while, but the time is separated with dot instead of colon which is expected by my current locale.

PostSave returns the time with dot as separator, but moment finds it invalid.

{
    "label": "Tid",
    "description": null,
    "view": "datepicker",
    "config": {
        "format": "",
        "offsetTime": "0",
        "defaultEmpty": "0"
    },
    "hideLabel": false,
    "validation": {
        "mandatory": false,
        "pattern": null
    },
    "readonly": false,
    "id": 25490,
    "dataTypeId": "33f5fd8e-9745-4e5c-ab08-ccdb0c9ce845",
    "value": "2019-08-29 18.30.00",
    "alias": "tid",
    "editor": "Umbraco.DateTime",
    "isSensitive": false
}

GetById returns it with a dot as well, but on load it is mapped fine. Gotta run for now. Will debug load as well if I get the chance later

{
    "label": "Tid",
    "description": null,
    "view": "datepicker",
    "config": {
        "format": "",
        "offsetTime": "0",
        "defaultEmpty": "0"
    },
    "hideLabel": false,
    "validation": {
        "mandatory": false,
        "pattern": null
    },
    "readonly": false,
    "id": 25490,
    "dataTypeId": "33f5fd8e-9745-4e5c-ab08-ccdb0c9ce845",
    "value": "2019-08-29 18.30.00",
    "alias": "tid",
    "editor": "Umbraco.DateTime",
    "isSensitive": false
}

[lars-erik]

There we go!
Tuesday, please? 🤣

[nul800sebastiaan]

Tuesday's release was closed yesterday. 😊

[nul800sebastiaan]

Fixed in #6138