Calendars.NET -- new platform, new issues

by Michael S. Kaplan, published on 2005/02/23 06:57 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/02/23/378804.aspx

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? :-)

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,

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.

douglas

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....