Calendars.NET -- new platform, new issues

by Michael S. Kaplan, published on 2005/02/23 06:57 -05:00, original URI:

Last month, I mentioned about Calendars on Win32 -- Not all there yet and Calendars on Win32 -- just there for show.... and really did not do much more than hint about what was going on in the world of .NET. Well, I have good news and bad news.

The good news -- in .NET, calendars are not "just for show." Every date you format is also one you can parse back, and even convert to another calendar. And that is pretty freaking cool.

The bad news -- they still pick up a few of the silly litle quirks that existed in Win32, like the poor localization story for everything other than Gregorian.

Of course, it is not just an issue of recyled bits retaining problems. There are also new issues as well.

Like (for instance) the fact that although none of the various calendars that derive from the Calendar class are sealed (so in theory you can inherit and extend any of them), that you cannot do anything useful by extending the interface yourself. Because all of the formatting and parsing work that .NET does is not built into the calendar itself -- there are no interfaces that a developer could implement in their own WayCoolCalendar class to answer the "how do you format ______?" or "How do you parse ______?" questions. The fact that the formating and parsing functionality comes from outside of the calendar itself seems to violate some sort of OO principle, though I would have trouble explaining which one. It just seems wrong to me.

Not to mention the fact that it is hard to "get out of the way" when one is blocking the path so fully! :-)

In my opinion though, the biggest problem is not a limitation, but a thorny conceptual issue -- how to distance calendars from cultures when it is appropriate. There are many new calendars being added to Whidbey that are very useful as converters but which cannot be directly plugged into cultures or custom cultures since they (a) do not have parsing/formatting support or (b) make no sense as a primary calendar for a locale. Now the first problem may just be a schedule/resources issue that will be addressed eventually, but the second will not be "fixed" since it makes no sense for the calendar itsef. Unfortunately, there is really no other place to put calendars. Users will simply try to use the new calendars based on the existing paradigm. To fit that, we have to fix the intuitive expectation of users that we created by using the same type (Calendar) in so many different places.

Which means we need a way to keep people from intuitively expecting that calendars like for example the ChineseLunisolarCalendar would be used for the default calendar of a culture. There has to be a way to describe them as supplementary calendars that have real utility without making people think that all dates that are formatted for a culture would use them.

And it is not like I would expect the JulianCalendar to be the default for any locale or culture. Though I know of more than a few software products inside and outside of Microsoft over the years that use the Julian calendar for internal build numbers. And I guess software developers make up an interesting subculture, if nothing else....

The dilemma, in a nutshell? How to explain that some calendars are "cultural" without really being expected to influence a CultureInfo.

Perhaps the switch from the word "locale" to "culture" will get in the way here? :-)


This post brought to you by "B" (U+0042, a.k.a. LATIN CAPITAL LETTER B)

# Leons Petrazickis on 23 Feb 2005 8:48 AM:

Well, one OO concept that is broken by breaking Inheritance is... Inheritance. Encapsulation is also ill-served.

# Michael Kaplan on 23 Feb 2005 8:52 AM:

Heh -- I did not just mean by breaking inheritance.

I also meant by having core functionalities for an object captured outside the scope of that object (or anything below it in the tree of ownership. Parsing and formatting need the fundamental information contained in a calendar to do their work and trying to capture it in the other direction (i.e. calendar as data provider) does not work since the algorithm behind the calendar is more important than the data items like the month names (which are also stored in the calendar anyway!).

# Michael Kaplan on 23 Feb 2005 9:00 AM:

Note that the above *is* a lot of encapsulation is -- I just did not want anyone to think I was stopping at the fact that you could not inherit the class as the reason I was worried.... :-)

# Douglas Husemann on 27 Feb 2005 8:55 PM:


I know I bugged this in the past believe it was between everett and Whidbey.

It would be nice if a standard timeline could be implemented. and then calendars could be built on top of that time line.

It would allow for some of the more estoric Business rules to be applied. Especially as the system becomes more "aware" with the advent of WinFS.

Believe me I have been around and watched this industry change from the old 4004 chip to when IBM went with the 86 series chips to working at AMD during the 486, 586, 686 days as contractor.

I understand the design decisions made given the hardware of the time. just wish those decisions were easier to unmake now.

It would be nice if the OS could understand that while my preferred cultural calendar is Gregorian with English Months. displayed in the US standard with slashes.

That I could have documents that require an overide on that system setting. Or any of the common in use calendars today.

Of course as discussed before I have needs outside of the norm. While I don't expect that MS to support Julian Calendars at any level it would be nice to have the capability to add it to the system and allow conversion between any other caledar implemented. either by third party ISV or other software from MS.


# Michael Kaplan on 27 Feb 2005 9:07 PM:

Hi Douglas,

Your post kind of went all over the map -- you should number the points next time! :-)

I am not sure how much of these decisions were truly hardware based, unless you are thinking about the Gregorian nature of SYSTEMTIME on Windows.

But in the .NET Framework, calendars are definitely rooted in the designs of their unmanaged ancestors.

Beyond that, there has been an intense interest in Avalon, XAML, and other newer platforms and documents in the notion of document level settings for those cases where people want them. I fear that many people ill misuse this setting and make for poorer international behavior. I will blog on this another time....

Most of the rest of what you want in regard to conversion is possible by ISV, today. Through any calendar that is supported on the .NET Framework....

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

referenced by

2010/02/22 Will someone take up the job of Calendar support in .Net, please?

2007/12/17 No good way to get one's Jalalis playing with calendars in Windows or .NET, really

2007/07/06 Upgrading the rank of the people we talk about calendars with

2005/12/02 Calendars in other languages

2005/10/20 Behold the PersianCalendar class

2005/03/28 The WinForms DateTimePicker and MonthCalendar do not support culture settings

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