Behold the PersianCalendar class

by Michael S. Kaplan, published on 2005/10/20 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/10/20/482896.aspx

I think I have pointed out in the past many of the flaws in the unmanaged, unmanaged, and managed calendar support in Microsoft products.

(I could probably supplement this with at least three posts of all of the expansions that various products like Outlook have done and how they may have actually made things worse rather than better in many cases, but that just highlights the fact that we do not solve all of the customer requests and people could not wait for us. It is (to asy the least) a bit cheeky to complain about those who are are at least trying to solve the problems!)

But to get back to the question of a Jalaali calendar, the best possible answer I could give is the new PersianCalendar class in version 2.0 of the .NET Framework. One step at a time, and this is a small step. But it is an important step....

The reason I suggest this particular solution is that calendars are very difficult to override completely, which is a lot of the reason for the reported difficulties that the original thread was highlighting.

Calendars are a somewhat unique problem when thoughts of how to "open it all up" and "get out of the way" are entertained, because of the fact that in most cases there is a lot more involved than just localizing names; there is a need to capture the algorithm as well, and finding a way to do all of that for both managed and unmanaged code (how else to work with custom locales?) while still handling the fact that many of the experts in such matters are not themselves programmers is a very difficult problem to solve in a generic manner.

Again I am not giving MS policy here, but it always seem to me that the reason people like Windows is that things simply work without them having to be programmers....

I can not say for sure, but sometimes I wonder if the reason that this kind of extension has not yet happaned has more to do with this difficulty in framing the problem and its customers then in the technical difficulties in calendars themselves.

But people are (and have been) thinking about the problems and how best to try to tackle them. This is a topic that I will post more on when there is mor to actually post....

Hi Roozbeh,

I notice that you mention a bug in the PersianCalendar implementation -- if it does exist, there is lots of time (way before 2089!) to fix the problem in a Whidbey service pack or in Orcas....

****Note to members of the GIFT test team -- someone should make sure Shelby tests the issue in http://advogato.org/person/roozbeh/diary.html?start=89 and if it repros, get that bug into the VSWhidbey database! :-)

Consider it done! Serisouly though, thanks for pointing out these issues, Roozbeh. Michael - I wish I had more time to read all your postings :-)

One of the issues that is sort of touched on in both posts here (and I'm sure others) is the difficulty of finding the "correct" and "official" algorithm and its implementation in the first place, then making sure that algorithm is correct for every location where a person might like to use such a calendar.

Michael, yes, it's not an important issue.

Shelby, the "correct" and "official" algorithm for the Persian calendar gets a little controversial at a few years after the date 2089 CE. I have tried my best, but I still don't have the exact official rule, as the law implemented in 1925 CE does not specify the locale.

The official rule is something like this: one should predict/observe the exact time of the March equinox, and then compare it to the time of the true (apparent) solar noon. If the equinox falls before the noon, this is the first day of the new year. If it falls after the noon, the next day is the first day of the new year.

The controversy rises because computing solar noon requires a locale. For Persian calendar of Iran, some people use Tehran, while others use the 52.5 E meridian (which defines the Iranian timezone). Afghanistan may have used a different locale for a while, or may have even switched to an arithmetic rule, but I have not been able to confirm the details.

According to the errata of the book Calendrical Calculations, the Tehran locale will start having different results from the Iran timezone locale in 2091.