billroper: (Default)
[personal profile] 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.)

Date: 2004-06-17 11:43 pm (UTC)
From: [identity profile] 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.

While I looked around at my possibilities

Date: 2004-06-18 07:04 am (UTC)
hazelchaz: (Default)
From: [personal profile] 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.)

Date: 2004-06-18 09:22 am (UTC)
From: [identity profile] pbristow.livejournal.com
...As I look around for my possibilities? Very apt. =:o}
poltr1: (Default)
From: [personal profile] poltr1
Oh hell. I did something like this at my last job, and it was done in both Perl and Excel. Thankfully, it was based on fiscal weeks, which ran from Monday through Sunday, so it was relatively easy to code....once I figured out how to do it. Alas, the source code stayed behind when I left, as per company procedure. But I remember the algorithm.

Date: 2004-06-18 07:05 am (UTC)
From: [identity profile] shannachie.livejournal.com
They have this Irish saying "When God made time, he made enogh of it". although seeing your problem he might have made a little more?
I like the 13 months solution. It is logical. Wasn't it the French revolution that tried to introduce it?

Date: 2004-06-18 05:42 pm (UTC)
From: [identity profile] kevinnickerson.livejournal.com
Isn't there a "Standard Accounting Practice" to deal with this? Throw it back at the accountants and make them tell you in writing what to do. With examples. ("The third day of the first week of the 13th months is May 7th")

Profile

billroper: (Default)
billroper

May 2025

S M T W T F S
     1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 3031

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated May. 31st, 2025 11:46 pm
Powered by Dreamwidth Studios