-1

I'm using the below code to detect the correct Persian date format.

        var formats = new[] { "yyyy/d/M", "yyyy/M/dd", "yyyy/MM/d", "yyyy/MM/dd" };
        DateTime dt;

        if (!DateTime.TryParseExact(date, formats, null, DateTimeStyles.None, out dt))
        {
            correctedDate = date.FixDate();
        }
        else
        {
            correctedText = date;
        }

The point is that there will be problems with some specific dates e.g. "1400/02/29". I've tried different CultureInfo and also DateTimeStyles but I still get the same result.

prodigy
  • 129
  • 1
  • 1
  • 6
  • 1
    [Does this answer your question?](https://stackoverflow.com/questions/10655116/how-to-convert-persian-calendar-date-string-to-datetime) – ProgrammingLlama Sep 28 '21 at 07:13
  • there's no `"yyyy/d/M"` format. If it begins with year then the next is always month – phuclv Sep 28 '21 at 07:16
  • Check this link, it might help you with your problem https://stackoverflow.com/questions/41951867/correct-way-to-use-persiancalendar-as-table-column-in-entity-framework – FrancoisVatCoke Sep 28 '21 at 07:17
  • 1
    @Llama Thank you the problem was solved with `CultureInfo persianCulture = new CultureInfo("fa-IR");` – prodigy Sep 28 '21 at 07:19
  • Check this post, might help you https://stackoverflow.com/questions/41951867/correct-way-to-use-persiancalendar-as-table-column-in-entity-framework – FrancoisVatCoke Sep 28 '21 at 07:22

1 Answers1

0

Are you aware that the date "1400/02/29" (which I understand as year 1400, month February, day number 29) does not exist?
Traditionally, a leap year is known as a year, divisible by 4, and that has indeed a day February 29.
However, this is not fully accurate: the full condition for a leap year is:

  • divisible by 400? Yes => leap year.
  • If not divisible by 400, divisible by 100? => Yes => NO leap year.
  • If not divisible by 400 and divisible by 100, is divisible by 4? Yes => leap year.

So, years, divisible by 100 but not by 400 (like 1400) are no leap years and as such, the date "1400/02/29" cannot exist.

So, it's well possible that the "wrong" behaviour you see is in fact "right" behaviour because your date is wrong.

Dominique
  • 16,450
  • 15
  • 56
  • 112
  • OP says "non-gregorian" in the title, and since the gregorian calendar was generally adopted in the late 1500s, and in the Julian calendar leap years were every four years without further conditions, it's a valid Julian date. Not saying it's necessarily representable in .NET's datetime but that doesn't make it a wrong date. – Damien_The_Unbeliever Sep 28 '21 at 07:52
  • @Damien_The_Unbeliever: The author says "*I give correct data to my program and the results are bad, so the program must be bad.*", on which I react "*Are you really sure your data are correct?*". It is not my intention to hardly state "*Dear author, your data are wrong!*", it's merely a remark. Normally, such remarks are to be put in a comment, but the remark is that big that it doesn't fit in a comment window, therefore I've written it as an answer. – Dominique Sep 28 '21 at 08:05
  • Yes, but what I'm saying is that you're applying a rule first formulated in the year 1582 to the year 1400. – Damien_The_Unbeliever Sep 28 '21 at 08:06
  • @Damien_The_Unbeliever: you're completely right. I'm just wondering if a computer knows this, seen computers have only been invented more than 400 years later :-) – Dominique Sep 28 '21 at 08:08