|
There is almost nothing more unpleasant in my job than trying to work with dates. Seriously, who came up with this crap? The horrible conjunction of year and month and week is simply the work of and endless stream of drunken monks and priests and it shows.
Let me give you an example of the horror I have to endure. Imagine, if you will, you have a set of data consisting of months. As an aside, I think months are evil and need to be permanently banished from our calendar. Well, for some reason companies love to do financials on the basis of these so called 'months', so it's not uncommon to have data based on month cycles. The problem with months is that while they, sensibly so, start at '1', they end all over the place, and the pattern, if you call call it that, is ugly and messy and not easy to work with in a clean manner. Especially February. Definitely February. So given this set of data, where each point of data is identified by a start point and represents a period of a month starting from that point, you need to pull all the data where the data intersects in time another data point. Easy right?
WRONG!
You've just been p3wned by a bunch of thirteenth century virgins. For you see, the month is a tricky beast. Not only does it represent the standard January, February, March etc. segments in time, but it can represent a chunk of time that is partially detached from the standard months. As a clear example, what is the end point of one month from January 15th? I bet most of you did not answer February first, but instead said February 15th. I'm sure some of you said February 14th, but you would still be in the month, and not fully a month from the point in time. Still, the math seems easy. Simply increment the month, right?
WRONG!
This method totally fails because the months do not have the same number of days. One month from March 31st is NOT April 31st. It's April 30th, not April 31st and not May 1rst. It gets even sillier with February which can't seem to determine just how long it is, hopping all over the place like a student waving his arm in the air trying to get the teachers attention so he can go to the bathroom because he just drank three mocha cappuccino lattes. One month from January 31st is either February 28th or February 29th. Ok, so this makes sense, no? Your ok with that last bit? Annoying, but workable, right? How about this; given the previous example, what is one month from January 28th? February 28th! February 28th is also one month from January 30th and 31rst! Wheeeeee!
And god forbid you need to step over months. January 31st goes to February 28/29th, right? And that goes to March 31st, and on to April 30th! Well, in the context of joined months, January 29th goes to February 28/29th. The next jump is NOT March 31st, even though one month from February 28/29th is March 31st. Nooooo, in the context of January 29th, the correct point in March is the 29th again! Two months from January 29th is March 29th, even though one month from January 29th is February 28/29th and one month from February 28/29th is March 31st. 1 plus 1 equals 2 except when 1 plus 1 do not equal 2 right? Or the sad truth is that one is not always one, but sometimes something else.
You begin to see my pain? How do you pull 'months' when a 'month' is a completely amorphous unit of time?! And of course, when working with large sets of data these so called 'months' are beginning all over the place, on the first middle and last and everything in between on every one of these 'month' things. And god forbid you add time to this. Imagine the horror of adding time! Daylight savings! Missing hours! Leap seconds! When is the beginning and end of a day?!!!
I hereby through my support whole hearted into the lets abandon months and daylight savings time initiative! Because leap seconds/days and the horror of weeks/years is enough cruelty.
:nuke: :rant:
|