Making Culture Invariant When Validating Date to negate deferent formats

[IbrahimMNada]

Prerequisites

• I have added steps to test this contribution in the description below

If there's an existing issue for this PR then this fixes

Description

when having languages such as Arabic as the default culture UI .Net automatic changes the Time format to Hjiri.
this caused an issue in the back-end validation for all datatype
as Peer the bug #17253

To fix this I just make the convert statement in datetime fallback to the default format which is the old good gregorian format

To Test This:

1. Create a new Document type that has date time picker.
2. logout then login for language cookie to reset
3. Make Your Back office default UI Culture Arabic ==> العربية
4. Create a new node from that document type and fill the date
5. Click save and publish successfully

[github-actions]

Hi there @IbrahimMNada, thank you for this contribution! 👍

While we wait for one of the Core Collaborators team to have a look at your work, we wanted to let you know about that we have a checklist for some of the things we will consider during review:

• It's clear what problem this is solving, there's a connected issue or a description of what the changes do and how to test them
• The automated tests all pass (see "Checks" tab on this PR)
• The level of security for this contribution is the same or improved
• The level of performance for this contribution is the same or improved
• Avoids creating breaking changes; note that behavioral changes might also be perceived as breaking
• If this is a new feature, Umbraco HQ provided guidance on the implementation beforehand
• 💡 The contribution looks original and the contributor is presumably allowed to share it

Don't worry if you got something wrong. We like to think of a pull request as the start of a conversation, we're happy to provide guidance on improving your contribution.

If you realize that you might want to make some changes then you can do that by adding new commits to the branch you created for this work and pushing new commits. They should then automatically show up as updates to this pull request.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[Matthew-Wise]

Hi @IbrahimMNada Thanks for the PR one of the community team will look at this as soon as possible

Matt

[Matthew-Wise]

Hi @IbrahimMNada I have been trying to replicate this issue, I did notice on the issue you mention your system language is ar-SA which might be a reason I cant replicate the issue :)

I have written a unit test which I think should replicate it but its passing every time.

I was wondering if you could give it a go and/or use this to replicate the issue

using System.Globalization;
using NUnit.Framework;
using Umbraco.Cms.Core.PropertyEditors.Validators;

namespace Umbraco.Cms.Tests.UnitTests.Umbraco.Core.PropertyEditors.Validators;

[TestFixture]
public class DateTimeValidatorTests
{
    [TestCase("en-US", "yyyy-MM-dd HH:mm:ss", TestName = "US Thread, DateTimeValidator")]
    [TestCase("en-US", "dd-MM-yyyy HH:mm:ss", TestName = "US Thread, DateTimeValidator ar-SA format")]
    [TestCase("ar-SA", "dd-MM-yyyy HH:mm:ss", TestName = "Arabian Saudi Thread, DateTimeValidator")]
    [TestCase("ar-SA", "yyyy-MM-dd HH:mm:ss", TestName = "Arabian Saudi Thread, DateTimeValidator US format")]
    public void DateTimeValidatorIsCultureInvariant(string culture, string format)
    {
        var dateString = DateTime.Now.ToString(format);

        var cultureInfo = new CultureInfo(culture);
        Thread.CurrentThread.CurrentCulture = cultureInfo;
        Thread.CurrentThread.CurrentUICulture = cultureInfo;

        var validator = new DateTimeValidator();
        var validationResults = validator.Validate(dateString, "DATETIME", new Dictionary<string, object>
        {
            ["format"] = format
        });
        CollectionAssert.IsEmpty(validationResults);
    }
}

[Matthew-Wise]

Is your database language in US? As there was a similar issue recently where this was the cause

Thanks
Matt

[IbrahimMNada]

Hello @Matthew-Wise , thanks for the reply ,

Just to make things clear , My System language is English , But my region is set to Saudi as the this image implies i think you could replicate this once you temporally set your region to Saudi (sorry for not mention that in the bug as I just found out about this)

Regarding the tests I will run them Right now.

And regarding the database my answer is : No , my data base is in English language but i think its the same situation with the region thingy , so if you need any further help with other bugs i will be more than happy to help

[IbrahimMNada]

Tests are all passed on the same machine Caused the Issue

Test with The Fix

I reverted my fix to previous and ran the test it failed when it came to Arabic
so i think we're good

Test When reverted The Fix

[Matthew-Wise]

Thank @IbrahimMNada for getting back so fast and adding the unit tests :D

Lets get this merged and tagged up

Matt

[nul800sebastiaan]

Hey all, these new tests never ran successfully:

Not sure what's going on but I don't think this is the correct solution to the problem.

I've reverted the PR for now (9056851) and would say this needs to be looked at again.

Changing a date compare is hugely dangerous, if you suddenly do the compare differently (with an invariant culture) then it will absolutely change for every culture. This means we need to be 100% sure it doesn't break for anyone and I just can't see how this change wouldn't have an effect on everyone else.

But in the end, I will admit, I don't quite understand the origin of the problem so that might give a clue as to what is actually wrong.

Sorry that this didn't make it in for now!