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
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:
# Michael Kaplan on 23 Feb 2005 8:52 AM:
# Michael Kaplan on 23 Feb 2005 9:00 AM:
# Douglas Husemann on 27 Feb 2005 8:55 PM:
# Michael Kaplan on 27 Feb 2005 9:07 PM:
2005/12/02 Calendars in other languages
2005/10/20 Behold the PersianCalendar class
go to newer or older post, or back to index or month or day