by Michael S. Kaplan, published on 2007/12/17 10:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/12/17/6779614.aspx
The question I received via the Contact link was:
Dear Michael,
we have a huge issues with Persian (Jalali) Calendar on WSS 3.0. We will appreciate if you can provide us with your input in this regard. it looks all Microsoft applications are getting the culture information from the Windows & .NET. We have just figured out some new things for Persian Calendar and specially correcting a Culture for Windows based on .NET.
the fact is that the default Calendar for this culture is "Gregorian" and either we have to override that or add a new one. Adding a new one is impossible (mscorlib.dll is locked and can not be edited) and also overriding is was not possible because even we overridden it (a code example is as below), we couldn't even return a simple string (No idea why it was so).
Public Class MyNewCalendar
Inherits GregorianCalendar
Public Overrides Function GetYear(ByVal time As Date) As Integer
Dim p As New PersianCalendar
'Return p.GetYear(time)
Return 1386
' Return MyBase.GetYear(time)
End Function
Public Overrides Function ToFourDigitYear(ByVal year As Integer) As Integer
Return 1386
'Return MyBase.ToFourDigitYear(year)
End Function
Public Overrides Function ToString() As String
Return "1386"
' Return MyBase.ToString()
End Function
End Class
We will appreciate your help and resources.
The history of pieces of System.Globalization that are and are not able to be overridden is pretty sordid to say the least.
There are two consistent principles that developers should keep in mind if they is developing against any of them:
Thus I was perhaps inaccurate (or at the very least misleading) to say that developers could count on these principles, as by definition counting on them means that you cannot count on the ability to override any of these classes in the long run....
So to start, the reason that you can't effectively override the Calendar class or any of its children is that the implementation has too many dependencies out side of the class that depend on internal/private members within it.
Also, remembering that calendars are irretrievably horked and broken in both managed (ref: here) and unmanaged (ref: here and here) code will also help here (note the "able to be overridden" issues were brought up in that post about managed code).
Now as a rule, the universal truth about the backassward and lame implementations of calendars in both unmanaged and managed code us very well understood. though people are hesitant to even try to plan all of the work to fix them as the sheer scale of the effort (and how it ties to date formatting, custom cultures, and date parsing) is quite daunting -- and every version thinking about the issues seems to happen too late to plan out all of the work that would be involved, let along do the work.
So people around these parts consider the fact that most of the major calendars that Microsoft wants to support are there and the few that are left are cheaper to just add to the list implemented by MS than to provide custom calendar mechanisms which would also require the aforementioned re-architecting.
Iranian/Farsi/Persian has its own issues here for Wassenaar Arrangement reasons and the various patent/copyright issues don't make it any easier either.
Are we having fun yet?
Okay, in that case I'll point out a potential workaround for the specific case of this calendar in managed applications -- discussed previously here and here -- the PersianCalendar class (renamed from the JalaliCalendar class, as it was called originally).
This won't work in unmanaged code as the calendar isn't supported there, and it cannot work as the default calendar for any of the cultures in .NET, as is explained in the topic:
Your application should not use a PersianCalendar object as the default calendar for a culture. The default calendar is specified by the CultureInfo.Calendar property and must be one of the calendars returned by the CultureInfo.OptionalCalendars property. Currently, the PersianCalendar class is not an optional calendar for any culture supported by the CultureInfo class and consequently cannot be a default calendar.
The reason for this limit is in theory simple enough -- because any culture can be the basis for a custom culture, and any custom culture can be a custom locale on Vista and Server 2008 -- which does not have this calendar. And therefore you can't put a calendar in that the system would not recognize.
In practice, I think this is a bad limitation -- in my opinion a more sensible one (considered, but eventually rejected) would have been to simply require that at least one calendar in the culture (i.e. some member of the CultureInfo.OptionalCalendars array) to be supported. who cares if the top of the list doesn't work, as long as one of the alternates do? :-)
As workarounds go the available one is fairly lame given all the limitations, though so far that has not been a significant enough limitation to lead to support for the calendar in unmanaged code. So until and unless that work happens, there is no good answer for how to have integrated support of the calendar in both managed and unmanaged code....
This post brought to you by ؍ (U+060d, aka ARABIC DATE SEPARATOR)