Calendars on Win32 -- just there for show....

by Michael S. Kaplan, published on 2005/01/14 14:32 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/01/14/353216.aspx

Obviously to some, claiming that calendars are just there for show may be a grating overstatement. But if you think about it, there are only four major purposes for the OS to support calendars:

1) Feed data for date formatting APIs so that dates that use a calendar can be properly formatted.

2) Provide data for the calendar itself so you could actually build a calendar if you wanted to.

3) Provide parsing capabilities so that you can take a formatted date string in a calendar and get the original date back for use in code.

4) Allow conversion so that dates that are in one calendar can be converted to another.

It is fairly obvious that if you have #1 and #3 then you have #4 anyway (since if you could format using any calendar and parse the string to get the date back, you can obviously "convert" between any of them. So you can think of these as user scenarios more than discrete features.

But the reason that I claim that calendars in Win32 are "just there for show" is that showing stuff us all you can really do with them. Only #1 and #2 are supported! To add insult to injury, even those two operations work for calendars that are supported within the context of the current user locale.

There is no support for either parsing or conversion. So make sure that the formatting operation is the last operation you do with a date before displaying it, since it is really the last thing you can do.

Side note: In fact, we found a synchronization bug in our code a few years back, related to constant user locale/calendar changing. It was reported by the Outlook team, who would be continuously changing the user locale to get calendar information from the NLS APIs for their "second calendar" functionality. It was kind of funny that we told them that they were misusing our functionality and they had to patiently tell to us that it was only to work around our functionality limitations. Oops!

There are other limitations to calendars on Win32, and there are of course the calendars on the .NET Framework that have a slightly better story, and I will talk about both items another time....

Finally an advocate on the inside for this weekness within the OS. ??

One of my favorite pass times is Genealogy. In very short order I run into the issue that.

1.)the lack of support for more than one calendar on the system at the same time.

2.)the lack of localization on documents. (for example. words insistance of suggesting October when working on a German documetn Oktober)

Personally I work in 3 different recent calendars on a daily basis.

Gregorian of course. Julian Calendar (with Russian months) and the French Revolutionary.

I have been told that LH still won't have support for multiple calendars which would be a shame. I even recommended a side by side format (called a historical date mapping) that allowed for a common date with a decent api that would allow for conversion. (of course that was related to the weekness that would come with WinFS and for show calendar system in the NT OS as it is now)

I do look forward to what you have to say. and yes .net does a little to help but needs to go much much further.

douglas

Ah, Julian has separate problems for Windows, since in the Windows model calendars only work within the context of a locale (and AFAIK no one really uses the Julian calendar like that these days).

Same for the French revolutionary, but even moreso!

Calendars are in their own way much harder than keyboards (which have MSKLC) and locales/cultures (for which Whidbey will have custom cultures and Longhorn will have solutions). Because both of those technologies require only data.

Calendars, on the other hand, require data plus an algorithm -- which makes it a lot harder to build a model to support, especially given the current architectures (which a lot of both Windows and .NET depend on). Especially given the limitations that the current architetures have which I mentioned some of in these couple of posts!

I can promise you that people are thinking about the problem, but this particular stew is messy enough that it will take a long time to cook....

I have talked to a few. and agree in some areas.

The context for calendars even get more sticky if you take into account Location awareness and account for the change in the calendar systems over history.

Julian calendars are used in Orthadox Religions even today. although the dates are usually transposed to the Gregorian calendar for political reasons. Most of your Russian observation for christian Holidays are reflected in that for exxample. Christmas is Jan 7 I believe this year. The year 2000 was one of the years that the Julian calendar gained a day in leap year.

You only have to go back 80 some odd years and you do run into Julian calendars.

I guess the main need I have is this.

While in day to day life a Locale is an OK thing, I need the ability to override that Locale in the documents that I deal with on a daily basis.

I deal in sources that can come from anywhere in the world and as far back as 100 B.C. currently.

It would be nice in a document store that it could be marked at a German Document in 1400's (unfortantly even the unicode standard hasn't fully encoded all the germanic charicars to accomedate that) but one can always hope.

I believe if MS put out a Real Genealogy program based on the needs of research and document storage over the last 2000 years most of those issues would have a way to get fixed.:) (I was starting with WinFS to look at that problem but unfortanly will have to wait a bit longer:(

thanks douglas

There is definitely a real scenario here, and I think people recognize that -- but it will take some serious thinking to decide what to do here (it is worth noting that the current model was based on sober thought about the specific scenarios in question, rather than some of the other scenarios to support in the future!).

Hang in there, though -- it would be unfortunate to work with data going back hundreds (even thousands) of years, yet worry about a few years for the proper representation and support!

:-)