Site Settings not working after setup "PRIVACY" section on multi language (fa-ir , ar-sa)

Description of bug

Site Settings not working after setup “PRIVACY” section on multi language (fa-ir , ar-sa)

Errors are listed in the screenshots section.

Steps to reproduce

List the steps to reproduce the behavior:

1. Go to ‘Site Settings’
2. Active multi language : example (en-us , fa-ir) or (en-us , ar-sa)
3. open website with fa-ir language
4. Go to ‘Site Settings > Site Behavior > PRIVACY’
5. Setup and Config ‘COOKIE CONSENT SETTINGS’ and ‘DATA CONSENT SETTINGS’
6. Save and Restart Application
7. Go to ‘Site Settings’ See error only (fa-ir , ar-sa)

Current result

Explain what the current result is.

Expected result

Provide a clear and concise description of what you expected to happen.

Screenshots

Main error :

Error log

root/API/PersonaBar/SiteSettings/GetDefaultPagesSettings?portalId=0&cultureCode=fa-IR error :

<Error>
<Message>An error has occurred.</Message>
<ExceptionMessage>String was not recognized as a valid DateTime.</ExceptionMessage>
<ExceptionType>System.FormatException</ExceptionType>
<StackTrace>
at System.DateTimeParse.Parse(String s, DateTimeFormatInfo dtfi, DateTimeStyles styles) at DotNetNuke.Entities.Portals.PortalSettingsController.LoadPortalSettings(PortalSettings portalSettings) at DotNetNuke.Entities.Portals.PortalSettings.BuildPortalSettings(Int32 tabId, PortalInfo portal) at Dnn.PersonaBar.SiteSettings.Services.SiteSettingsController.GetDefaultPagesSettings(Nullable`1 portalId, String cultureCode)
</StackTrace>
</Error>

Additional context

Add any other context about the bug that may be helpful for resolution.

Affected version

• 10.0.0 nightly build
• 9.4.1 nightly build
• 9.4.0 latest supported release

Affected browser

• Chrome
• Firefox
• Safari
• Internet Explorer
• Edge

[valadas]

I did not have time to test this but assigning to 9.4.1 for now

[donker]

A fix has been merged into the 9.4.1 release. This should fix the issue. If you see any more issues try resetting the consents using the button on the Site Settings screen while logged in with a locale that has access.

The core of the issue is the way the date is stored in SQL in the PortalSettings table (key = “DataConsentTermsLastChange”). This was done using a generic universal format. It will now be stored in a so-called round-trip format (more robust to storage and retrieval).

It impacted (as far as I can tell) only non-“Western” sites (i.e. ones with divergent calendars from the Gregorian that we use) under that locale.