Re: Year 2000

RE:     Re: Year 2000

Al,

>> The problem with date data types is more than performance.  Zero dates are
>>  special values are not supported.  Also invalid dates blow up.  How clean
>>  is your data?  Do you have a field in your A/R system for 'date paid'? Do
>>  you have a field in your payroll system for 'date of termination'?
>>  It's not that straight forward. - -  Al barsa

>Now THIS is the sort of information that I was looking for on this subject!
> As I mentioned before, performance was an afterthought.  BPCS allows zeroes
>as a beginning effectivity date on a bill of material, with all 9's as an
>end.  From what you stated, I'd assume that date fields are out of the
>question for us...
>Thanks!
>Dean Asmussen

Dean 
[[[ Before I begin let me say that following is only to bring out the point
that "We have problems now" with our data. Those problems were not caused
by date/time types. 
We've been using date/time data types for all new development for the 
last 2-3 years. Starting back on V2R3 using them with RPGIII(it wasn't
that bad with RPGIII) Since that time we put in a couple of major systems
and have not seen any negitive aspects.  They work easily, no noticable
performance problems, they work great with Query/400, etc.  Every file
created has a creation timestamp and last modified timestamp. ]]]

No problem.

- - This section refers to your comment.----

This is the decision making I was talking about.  Why are they out of the
question?  You have "Special" values in date fields NOW. When your programs
see "00/00/00" or "99/99/99" they "DO SOMETHING SPECIAL".  Is 00/00/00
or 99/99/99 a valid date?  NO. Its a "Special Value" whose meaning is 
only known via the imbedded logic of your application code! That meaning
is not readily known to the outside world(Query, User extractions, etc)

Why can't your programs interpret 01/01/0001 the same way as 00/00/00?
Why can't 12/31/9999 be your "infinity"?  If you don't want to, 
thats fine.  But you can't honestly say dates won't work.  You
CAN say "I don't want to go thru the effort required to translate our
current imbedded 'special values' to a new 'special value' format"

You at the same time are saying that "The users who buy BPCS will never
be able to do date math using their own query tool now or 5-10 years
from now" Thats a heck of a decision to impose on the users/owners
of that data base.

Why does BPCS allow 00/00/00 as a beginning effectivity date?  Why is that
valid?  Having programmed in manufacturing for nearly 20 years I know that
it was a conscious design decision.  When a user enters a Effectivity date
you could have made it effective as of TODAY.  

Because we programmers use 00/00/00 or 99/99/99 or 12/31/99 or any other
"SPECIAL VALUE" its our problem not date/time types.

But I'm probably wrong.

John Carr
EdgeTech



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the Midrange System Mailing List!  To submit a new message,   *
* send your mail to "MIDRANGE-L@midrange.com".  To unsubscribe from     *
* this list send email to MAJORDOMO@midrange.com and specify            *
* 'unsubscribe MIDRANGE-L' in the body of your message.  Questions      *
* should be directed to the list owner / operator: david@midrange.com   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *