Re: Date Comparison yyyymm

On Wed, Oct 11, 2017 at 12:04 PM, Rob Berendt <rob@xxxxxxxxx> wrote:

I just don't see how it would be any less disruptive to move from 5 digit
dates to 7 digit dates than it would have been to go to a DATE field.
Unless you were still doing a lot of RPGII or some such thing (which may
have been more likely 18 years ago).

Well, not RPG II but RPG III. And remember this WAS 18 years ago
(actually closer to 19 in this case).

There's the usual concerns about double meanings. For example a date of
all 9's means something special. Then again a DATE of 1666-01-01 could
mean the same thing.

The company I worked for had pretty clean software, and pretty
well-established conventions. (I didn't know it at the time, because I
hadn't worked anywhere else.) So if there were any special 5-digit
values, they would have mapped exactly (and straightforwardly)
one-to-one to special 7-digit values. 5-digit all 9's to 7-digit all
9's involves no "logic" changes at all. In a lot of cases, that can be
accommodated simply by recompiling. Same goes for zero.

It is clearly MUCH MORE disruptive to move to true date fields,
because the special values aren't valid dates, so you have to pick new
special values which ARE dates, and/or introduce nulls, which no one
could sanely argue is less disruptive in a system that doesn't already
have them.

And as far as disk space goes, one has to remember that DSPPFM does not
tell you really how many bytes a date field takes. That was customized,
along with RPG buffers and everything else, so that older versions of RPG
could process it as a string. I think you'd have to either find the
documentation, or delve down into DMPOBJ or some such thing.

Disk space was not a consideration for them, but if you need to know,
it's not THAT hard to find the documentation. (Or search the archives
of this list. And now I see Bruce has added this information yet again
in this very thread.) A true date field takes 4 bytes on disk, same as
7 packed digits.

John Y.