Does your code avoid the [government sanctioned] Y1.45K bug?

by Michael S. Kaplan, published on 2011/06/15 07:01 -04:00, original URI:

So I was asked if I knew what the following comment from the site was about:

The Microsoft Implementation of the Umm al-Qura Calendar

The implementation of the Umm al-Qura calendar in Microsoft’s recent operating system Vista is claimed to be valid between 1318 AH and 1450 AH. However, as the Microsoft Vista algorithm erroneously assumes that the computational rule used between 1395 AH and 1419 AH was also used before 1395 AH the Microsoft algorithm will often give faulty results for dates before 1395 AH.

I am really not sure what this comment refers to.

I mean I have mentioned issues I know about in blogs like Long term planning is not always done, and Using a culture's format, without using that culture to format?.

Not to mention Evil Date Parsing lives! Viva Evil Date Parsing!, explained.

Or Grody to the Max[Date]!.

Even without issues that would cut down our effective dates, looking to the future the 1450 limit would take us to (unless my mental math is off) some time in 2028, which is not that many years away.

With computer programs written in .Net that work with MaxDate so gratuitously (and I have seen many of those), this is not a very wide range.

Given that there are features in Windows that can deal with dates outside of this range (including certificate creation), I think any application running on Windows that doesn't handle the Um al-Quara calendar is pretty irresponsible....

By the way, does anyone know what that "bug" in our implementation is? I'll ask some people around here, but I thought I'd ask my readers first in case anyone knew.

ray on 15 Jun 2011 1:43 PM:

Don't worry, it's just a calendar rule change that happened in 1395... (1975 in Gregorian years)

Michael S. Kaplan on 15 Jun 2011 4:44 PM:

There's still the 1450 stopping point, so I'm still worried. :-) on 16 Jun 2011 1:41 AM:

The above comment (regarding the accuracy of the Microsoft Vista implementation of the Umm al-Qura calendar before 1395 AH) is from

where you can find a date converter valid between 1356 AH and 1500 AH.

Mike Dimmick on 16 Jun 2011 10:47 AM:

Digging around in the .NET source code, I can see that .NET 3.5 SP1 'red bits' and .NET 4.0 RTM both are just based on a table lookup that runs from 1318 AH to 1450 AH. There's no reason that the table couldn't be corrected if the historical record shows that it's wrong, except of course for compatibility reasons (it may be wrong, but it's consistently wrong). The web page referenced by (his/her own, apparently) says 'Dates for the years 1356 AH to 1411 AH are based on a calendar conversion table published in the early 1990s by the King Fahd University of Petroleum & Minerals Research Institute (Dhahran)' so are probably correct.

The calendar on that page is also table-based, but this goes up to 1500 AH. That's why it says the results are wrong after that point!

The only real solution is to incorporate astronomical calculation software into Windows so that it can calculate any date in the future. Developers and users might be surprised at how long it's taking to figure out the date, though!

HijriCalendar is a specific tabular calendar that alternates 29 and 30 days per month, and a fixed schedule of 'leap years', so can be projected indefinitely into the future.

go to newer or older post, or back to index or month or day