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.


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:

Sounds like you need to have a chat with Jon Skeet about noda time.


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

Well it might be a little more complicated in that case, but I'd look over the specs (Neither Noda or Joda does the Amharic numbers!)....

John Cowan on 22 Feb 2010 10:02 AM:

Or you could just give the developers of NodaTime, an "idiomatic port" of JodaTime to .NET, a little boost.

Kemp on 22 Feb 2010 10:14 AM:

You seem to have a reference to footnote 1, but no footnote 1. My mind threw a parsing error ;-)

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

I decided not to do that, but did not remove the footnote. Hope this helps with your parsing error!:-)

Jon Skeet on 22 Feb 2010 11:54 AM:

Michael: This is the first I've heard of Amharic numbers, but Joda Time does support the Ethiopic calendar:


So Noda Time will eventually support that calendar too.

I doubt that we're up to coping with a new number system, but we could certainly talk about it.

If the BCL team wanted to take Noda Time into the BCL in some way, that could provide some, er, interesting challenges. I think for the moment it's best on its own as an open source project - that doesn't seem to have hurt Joda Time much. While we won't be able to change DateTime/DateTimeOffset themselves, we'll have our own *much* better types - which will of course have conversions to DateTime/DateTimeOffset if you really want...

Mail me (or the mailing list) if you're interested in finding out more...

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

I'm guessing the BCL won't be picking up Noda Time any time soon. :-)

The numbering system is something that there is a true generation gap about but not doing it shouldn't mean not doing the calendar, so I'm glad you'll do it.

If folks here don't want to do it or can't then I'm happy to recommend someone who will do it, especially if it is easy enough to use with existing mechanisms (haven't looked at it yet or anything so can't say for sure)....

Brian on 23 Feb 2010 2:15 PM:

How about you get your management to commit Bala's team to do this feature?

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

My management can't control their resources, thus my plea here. This was easy back in 2005 when I first suggested it too....

referenced by

2011/06/21 The downside of managing to go native...

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