by Michael S. Kaplan, published on 2006/04/14 16:05 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/04/14/576627.aspx
Starting in the 2.0 version of the .NET Framework, Microsoft has had the UmAlQuraCalendar Class, which is a more secular version of the HijriCalendar class in that it is based on a table-based algorithm, and does not support the "advance date" functionality I have talked about in the past.
While still somewhat controversial with religious authorities who object to a calendar that is not based on the moon sighting (just as they object to technology to help with the sighting in some cases), it is to others a reasonable compromise for the need to have a more predictable calendar in the secular world.
Which is not to say there are not some limitations.
Try the following code:
using System;
using System.Globalization;public class Test
{public static void Main()
{
DateTime dtLater = new DateTime(2030, 1, 1);
UmAlQuraCalendar uaqc = new UmAlQuraCalendar();
DateTime dtMuchLater = uaqc.AddMonths(dtLater, 1);
}}
The clever among you might object that this code does nothing with the date it has calculated, so what is its's point?
Well, try it out and compile it. Once you run the small application, here is what it will say:
Unhandled Exception: System.ArgumentOutOfRangeException: Specified time is not supported in this calendar. It should be between 04/30/1900 00:00:00 (Gregorian date) and 05/13/2029 23:59:59 (Gregorian date), inclusive.
Parameter name: time
at System.Globalization.UmAlQuraCalendar.CheckTicksRange(Int64 ticks)
at System.Globalization.UmAlQuraCalendar.GetDatePart(DateTime time, Int32 part)
at System.Globalization.UmAlQuraCalendar.AddMonths(DateTime time, Int32 months)
at Test.Main()
Hmmm... that seems like a problem, doesn't it?
Well, it is working as designed, per the docs:
Remarks:
The UmAlQuraCalendar class is nearly identical to the HijriCalendar class, except the Saudi Hijri calendar uses a table-based algorithm licensed from the Saudi government to calculate dates, can express dates to the year 1450 A.H., and does not support the HijriAdjustment property.
And one of the downsides of a table-based calendar is that until tables exist there is no especially good answer on what to do other than throw an exception (the moral equivalent of walking off the end of the table).
But certainly such a problem can have an impact on being able to use the calendar in everyday secular matters, couldn't it?
Obviously something better will have to happen here for people to be able make appropriate use of it as a calendar in many different scenarios....
This post brought to you by "ޓ" (U+0793, a.k.a. THAANA LETTER TAVIYANI)
# Maurits [MSFT] on 14 Apr 2006 8:05 PM:
# Michael S. Kaplan on 15 Apr 2006 9:35 AM:
# Michael S. Kaplan on 15 Apr 2006 9:38 AM:
# Maurits [MSFT] on 15 Apr 2006 1:32 PM:
referenced by
2011/06/15 Does your code avoid the [government sanctioned] Y1.45K bug?
2011/02/26 Why I don't like the JapaneseCalendar class #1: Respecting (or at least admitting) the history....
2010/02/12 Evil Date Parsing lives! Viva Evil Date Parsing!, explained
2008/12/16 Grody to the Max[Date]!
2006/09/29 .NET is too busy being consistent with Windows to be consistent with itself....
2006/09/18 More on changes to the Hijri calendar?