Long term planning is not always done

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:

... well... in... principle... you... could... um...

(shudder)

(deep breath)

Create publishing points
http://globalization.microsoft.com/calendars/UmAlQura-Tables
http://globalization.microsoft.com/calendars/Hijri-ConfirmedMoonSightings

Have .Net clients connect to these publishing points under controlled circumstances

Have them store the latest data in some kind of local cache so they don't have to requery every time they're run
(release)

Oy.

It's fun to laugh at religious control of science.  But at least they didn't try to make π = 4
http://www.straightdope.com/classics/a3_341.html

# Michael S. Kaplan on 15 Apr 2006 9:35 AM:

Of course in Indiana (according to my sources and the article you cite) they did not make a claim based on religious grounds....

# Michael S. Kaplan on 15 Apr 2006 9:38 AM:

Oh, one other thing! A web service will not help the immediate problem; it will only make updates easier. The fact that the standard for the new calendar is not going to work for reasonable dates is still a problem (and it has tried to get away from the religious overtones)....

# Maurits [MSFT] on 15 Apr 2006 1:32 PM:

> A web service will not help the immediate problem; it will only make updates easier

Indeed.  The nondeterministic status of the calendar is not a problem that can be fixed.  Updates will be more and more important to any users of this calendar as we approach 2030.

> the standard for the new calendar is not going to work for reasonable dates is still a problem

But a fundamental one (rimshot)

Leap seconds have the same problem, which (I suppose) is why nobody implements them, and just leaves it to the internet NTP servers to slew our clocks by a second every 18 months or so.

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?

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