Fun and Games With Dates

[billroper]

There are dates that are fun. Then there are dates that aren't.

In this case, these aren't dates you go out on, nor are they dates that you eat. They're dates that exist on a calendar.

Right now, the date when I need to finish my current project at work is approaching like an onrushing train and I discover that one of my major problems is figuring out how to convert between dates that exist on a calendar and dates that only a financial guy could love. You see, I need to figure out when events are going to occur, based on contracts that specify real dates that exist on a calendar. Most of the models in our product are based in calendar time, so there's no problem at all finding the real calendar date that matches. (Well, a few small problems, but they're easily solved.)

But there are three kinds of year that we support that don't match up with a real calendar:

12-month years with 360 days
12-month years with 364 days and months containing 4 or 5 weeks
13-month years with 364 days and months that all contain 4 weeks

I know what the easy solution is -- other than not supporting them, which is right out. I'm just trying to convince myself that our users will be ok with the easy solution. (Which is dumping the extra days in the last month of the fiscal year and letting God sort them out. This would be easier if I weren't God in this case.)

Comments

[tigertoy.livejournal.com]

I hope you're just venting and not looking for advice, because only a pointy-haired boss could actually tell you how to handle such a mess without more information than you've given us.

[billroper]

Yup, this is venting. But, at least, it's creative venting.

Time, time, time, see what's become of me...

While I looked around at my possibilities

[hazelchaz]

and your boss is so hard to please.

I assume you have a set of serial date conversion library subroutines? Gods bless Zeller.

(Serial date is sometimes misnamed Julian Date. Zeller's Congruence is named after the mathematician who noticed that if you start the year with March and end it in February, it's easier to calculate dates because there are 30.6 days per month and you just round off to get the appropriate whole number of days. Example, rounding off you get 31 days for March; 30.6x2 = 61.2 = 61 for March+April, and so on. The nice thing about that is you can work it in reverse... you still need to do the 365.25 days per year calculation, but once you've determined the start of the year - that is, March 1 - you can divide by 30.6, add a fudge factor and round down to get the number of months, and so on.)

Re: While I looked around at my possibilities

[billroper]

I hadn't heard of that particular trick, but it's a cute one.

For calendar dates, I'm using the COleDateTime class that MFC provides (and which -- I suspect -- is optimized to use some of these tricks).

When I'm dealing with non-calendar dates (which occur in those pesky 360-day and 364-day years), I do my own calculation, but those are much more regular than the real calendar. The problem is in mapping the calendar dates onto the non-calendar time periods, but I think what I'm going to do is work with elapsed days from the start of the year; then ram the extra days into the last month of the fiscal year. I won't calculate interest on those days, but if a payment is due in that range, I'll do it on the last day of the fiscal year.

[pbristow.livejournal.com]

...As I look around for my possibilities? Very apt. =:o}