String was not recognized as a valid DateTime - but it runs smoothly in another server

Question

My current Win 2008 R2 server migrating to Azure. So that Im moving a web application to Azure Server Win 2008 R2.

Currently, I am facing the issue where it shows

"Message":"String was not recognized as a valid DateTime.","StackTrace":" at System.DateTimeParse.Parse(String s, DateTimeFormatInfo dtfi, DateTimeStyles styles)\r\n at System.Convert.ToDateTime(String value)\r\n at... `

Purpose of the code: Its a JQGrid library, If the code runs successfully, I will proceed to update a table. This code runs when user clicks the update button and before updating the table as validation of date.

Weird question is: My On-Prem server runs this code smoothly, all data in Azure and On-Prem server are same.

NEWLY ADDED: When I edit some rows (so far only 1 row out of 100), it works.

Working row details:

Not working row details:

JQuery code snippet:

        closeAfterEdit: true,
        closeOnEscape: true,
        reloadAfterSubmit: true,
        url: '/SFI/WebService/StaffMaster.asmx/CheckEditStaff_AssignedRoster',
        ajaxEditOptions: { contentType: 'application/json; charset=utf-8' },
        mtype: 'post',
        datatype: 'json',
        serializeEditData: function (postData) {
            var PrivilegeID = $('#hdnMAPrivilegeID').val();
            eStaffID = $("#StaffID").val();
            eStaffNo = $("#StaffNo").val(),
            eNewEndDate = $("#EffectiveEnd").val();
            eStaffName = $("#StaffName").val(),
            eIdentificationNo = $("#IdentificationNo").val(),
            eDOB = $("#DOB").val(),
            eEffectiveStart = $("#EffectiveStart").val(),
            eEffectiveEnd = $("#EffectiveEnd").val(),
            eGradeCode = $("#GradeDetails").val(),
            eStaffType = $("#StaffType").val(),
            eOrgUnit = $("#OrgUnit").val(),
            eEmail= $("#Email").val().toLowerCase()

            return JSON.stringify(
            {
                StaffID: $("#StaffID").val(),
                NewEndDate: $("#EffectiveEnd").val(),
                OldEndDate: StaffOldEndDte
            });
            .
            .
            .
            StaffOldEndDte = $("#EffectiveEnd").val();

Web Service Call in C#:

    public string CheckEditStaff_AssignedRoster(string StaffID,string NewEndDate,string OldEndDate)
    {
        string status = "0";
        bool Changed = false;
        DateTime dtnew;
        DateTime dtOld;

        dtnew = Convert.ToDateTime(NewEndDate);
        dtOld = Convert.ToDateTime(OldEndDate);


        if ((dtOld != dtnew)  && (dtnew < dtOld))
        {                
            Changed = true;
        }
        else
        {
            status = "1";
        }

        if (Changed)
        {                
            if (some condition...)
            {
                .
                .
                //do something...
            }
            else
            {
                status = "1";
            }
        }

        return status;
    }

most probably the two servers have different culture, thus datetime format. If Azure is in US it will have MM-DD-YYYY and maybe your onpremise server has DD-MM-YYYY — apomene, Feb 04 '20 at 10:54
@apomene. I have provided the screenshots of working rows and non-working — Shereif SRF, Feb 04 '20 at 11:05
As per yellow highlighted rows, it is clear that you have culture issue. 31/12/9999 is a valid DT if date format is DD/MM/YYYY where as if your format is MM/DD/YYYY it is invalid datetime — apomene, Feb 04 '20 at 11:08
@MohammedShereif *don't* store dates as strings to begin with. If you *have* to, use the ISO8601 format, ie `YYYY-MM-DD`. In JavaScript, use [toISOString](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toISOString). This is a problem in the code, not .NET or Windows. — Panagiotis Kanavos, Feb 04 '20 at 11:09
@MohammedShereif the de-facto standard for dates in JSON is the ISO8601 format anyway — Panagiotis Kanavos, Feb 04 '20 at 11:09
@MohammedShereif what is `EffectiveEnd`? A text input? jQuery Date picker? Or an `input` with a `date` or `datetime` type? In all those cases you can get a `Date` object instead of a string — Panagiotis Kanavos, Feb 04 '20 at 11:11
@PanagiotisKanavos, it a column which is in `formatoptions: { srcformat: 'd/m/Y', newformat: 'd/m/Y' }` — Shereif SRF, Feb 04 '20 at 11:16
@MohammedShereif I asked about the HTML element, not the column. What is it? What you send to the server, any server should *NOT* use a localized format. The way to fix this is to read the date from the input element as an ISO 8601 string — Panagiotis Kanavos, Feb 04 '20 at 11:43

score 1 · Answer 1 · answered Feb 04 '20 at 10:58

As mentioned in the comment before, different cultures might be the problem. Using InvariantCulture in your code might help. More info here: https://learn.microsoft.com/en-us/dotnet/api/system.globalization.cultureinfo.invariantculture?view=netframework-4.8

score 0 · Answer 2 · answered Feb 04 '20 at 10:58

Here's your problem: Convert.ToDateTime.

Here's the source code of this method:

public static DateTime ToDateTime(String value) {
    if (value == null)
        return new DateTime(0);
    return DateTime.Parse(value, CultureInfo.CurrentCulture);
}

As you can see, it uses the current culture to parse the string.

What you should be using is DateTime.TryParseExact or at least DateTime.ParseExact and give it the exact format and correct culture info you're attempting to parse to DateTime.

score 0 · Answer 3 · answered Feb 04 '20 at 10:58

Change your lines:

    dtnew = Convert.ToDateTime(NewEndDate);
    dtOld = Convert.ToDateTime(OldEndDate);

To

    dtnew = DateTime.ParseExact(NewEndDate, "yyyy-MM-ddTHH:mm:ssZ", CultureInfo.InvariantCulture); //or however your JS is formatting the date as string
    dtOld = DateTime.ParseExact(OldEndDate, "yyyy-MM-ddTHH:mm:ssZ", CultureInfo.InvariantCulture); //or however your JS is formatting the date as string

If you have a Date in JS and you use toJSON it should return a string in "yyyy-MM-ddTHH:mm:ssZ" - see The "right" JSON date format for more discussion

score 0 · Accepted Answer · answered Feb 04 '20 at 11:35

0

After knowing some knowledge on different cultures on DateTime format, from the question's comment, I moved to search again on how to make it the same as my on-premise server to new azure server (Because I have already developed a working code in my on-premise server). Found that, i can just change the 'Region and Language' setting same as on-premise to azure. Below is the link I used.

Here is the link: From where CultureInfo.CurrentCulture reads culture

answered Feb 04 '20 at 11:35

Shereif SRF

58
1
12

1

That's not a fix, this covers up the problem. When you try to call another service you'll end up with the same problem - no service expectes localized dates, all expect dates in the ISO8601 format – Panagiotis Kanavos Feb 04 '20 at 11:44
@PanagiotisKanavos, yes, this is a lesson for me to use the standard formats in future developments. I posted this answer for those having the same as my situation. Because it took 2.5 days just for this fix. – Shereif SRF Feb 04 '20 at 11:46

String was not recognized as a valid DateTime - but it runs smoothly in another server

4 Answers4