Will someone take up the job of Calendar support in .Net, please?

by Michael S. Kaplan, published on 2010/02/22 07:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/02/22/9967111.aspx

Calendar support in Microsoft products.

Sigh....

Within the first few months of this Blog, I wrote Calendars on Win32 -- Not all there yet and Calendars on Win32 -- just there for show...., followed just 8 days later by the first managed foray into the topic (Calendars.NET -- new platform, new issues).

Occasionally there was good news for Saudi Arabia or for Iranexpatriate Iranians or India or whatever.

But by and large the question I first posed to my very first manager in Windows almost a decade ago ("When can we make calendar support not stink?") remains largely unanswered.

Whether one targets the native side or the managed side, the fix would involve a hell of a lot of work - largely a rewrite for the former, largely a new class and a major refactoring for the latter (with the even larger question of how to support custom calendars that would have to somehow work in both environments left aside for another day).

Obviously I can't describe what the rewrite would need on the Windows side all that effectively since I can't really describes too much about the internals as they stand. So we'll table that one for now; I tend to doubt that there is much hope for that work being done, to be honest.

The former paragraph is my personal opinion about a kind of political situation, not at all a real technical issue.

But the managed world, I hold out more hope since there is a team over in the Developer Division that occasionally does some major work in this area.

The biggest piece of the work would be the refactoring - the current organization between DateTimeFormat, the various Calendar classes, and the parsing and formatting arms of DateTime is very poorly organized for the job of adding new calendars (you can use .Net Reflector to see some of this, you can probably just take it as read the huge dependency each class has on internal knowledge of the fixed tables in Microsoft's data that makes this such a Herculean task.

Here is my humble suggestion for someone who wanted to tackle the Calendar issue for .Net, as a step by step task-list:

1. Come up with a new name for the new Calendar class; surprisingly, coming up with an acceptable name might be the hardest part of this entire exercise!
2. Make sure you have the complete understanding of your calendar figured out - how to convert any date between it and the Gregorian calendar, from soup to nuts. You'll need this.
3. Decide if you want to support more than one language to express the dates/times in, and if you do then add a UICulture name sort of thing to support it. This part is optional.
4. Write a method that will take a DateTime and a standard or custom date/time format string, and format it into a string using your calendar's logic. This will be used by a ToString method later.
5. Write a method that will take a a) string and b) a standard or custom date/time format string and do an exact, literal parse into a DateTime using your calendar's logic. This will be used by a ParseExact method later.
6. Write a method that will take a string and do a "parse under any circumstances if it is in any way possible" into a DateTime using your calendar's logic. This will be used by a Parse method later.
7. If your calendar has other day names/month names and so forth then fill out all the information for a DateTimeFormat kind of thing that has those names in it.
8. What to do here depends on whether you are internal to Microsoft with the authority to change the BCL (Base Class Libraries) of .Net or not:
1. If you can make the changes in .Net, make sure that the existing DateTime, DateTimeOffset, CultureInfo, and other classes are modified to be able to consume your new calendar class with the new cool name figured out in step 1. Call me if you need any help with this!
2. If you cannot make the changes in .Net, then make sure the methods in steps 4-6 above are easy to call and release it as is. You are done. Call me if you want someone to help try it out when you're done for an interesting calendar!

Now this also "solves" the custom calendar issue for managed code, one way or the other. It leaves the Win32 case broken but that would definitely require resources elsewhere (I would love to see it but I'm not going to rely on it).

For the record this process above is just a more fully fleshed out version of the thing I first suggested almost five years ago in Calendars.NET -- new platform, new issues, but I'm hoping that the expanded information will inspire someone (or multiple someones!) to do the work and tell other people once it's done.

Plus note that if you do the Ethiopic calendar I mentioned the other day in The road not traveled (or, more to the point, the road not built) for Amharic, you can use the Ethiopic number system since you are the one doing all the parsing and formatting anyway - try exposing those Parse and Format methods too and help prove how easy it would have been for them to do it!

As I said above, let me know if you start doing all this, I'd love to see someone pick up the torch on this one since no one seems to be dong it yet and my former call to passion (opening it all up and getting out the way) is really wishing more could be done here, by someone. By anyone....

Peter Ibbotson on 22 Feb 2010 8:48 AM:

Michael S. Kaplan on 22 Feb 2010 9:46 AM:

John Cowan on 22 Feb 2010 10:02 AM:

Kemp on 22 Feb 2010 10:14 AM:

Michael S. Kaplan on 22 Feb 2010 11:27 AM:

Jon Skeet on 22 Feb 2010 11:54 AM:

Michael S. Kaplan on 22 Feb 2010 12:25 PM:

Brian on 23 Feb 2010 2:15 PM:

Michael S. Kaplan on 23 Feb 2010 4:02 PM:

referenced by

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