On Thu, Nov 11, 2021 at 4:10 PM Greg Wilburn
<gwilburn@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
I use something that "came with" DB Web Query - a table called DATE_CONV. It's a lot faster than having a function.
Mine only goes to 12-31-2030
We're getting uncomfortably close to 2030 for my taste. And lots of
Y2K "solutions" involved the 100-year window from 1940 through 2039.
Well, for those folks (which unfortunately includes where I work),
we've used up more than half of the 40-ish-year runway that we bought
for cheap back in 1999! (Or, I guess I should say: the people that
made the decision to go that route have left their successors less
than half of the runway that they bought for cheap back in 1999.)
Personally, my reasons for choosing the window that I did were:
1. First and foremost, I don't trust other people to get the leap-year
calculations right, and I have seen home-grown routines from back in
the RPG III days that will be incorrect in 2100 (if they even survive
the 1940-2039 window). The current calendar rules are periodic with a
cycle of 400 years.
2. I chose 1900-01-01 as the start because that's where Excel's dates
start, and I know that our business hasn't ever and won't ever have to
deal with dates earlier than that.
3. 400 years *feels* like "more than we'll ever need"; yet a file to
store 400 years worth of data is still pretty small by even my
company's meager computing standards. I know other shops where a date
conversion file covering 4000 years would seem kind of small. They
might opt for the full 0001-01-01 through 9999-12-31.
And yes, I'm familiar with Y10K Cobol jokes. But I fully expect that
by then, a Skynet-style AI will be in control of everything, and
whether humankind even exists at that point is irrelevant.
John Y.
midrange.com
