× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Date *HIVAL was Urgent!!! NULLS & ZEROS
  • From: "Scott Klement" <infosys@xxxxxxxxxxxx>
  • Date: 22 Dec 1999 14:08:39 -0600

Hmmm...   I like the date data type, and can certainly argue the case
for it...  but I'm not sure that the argument that it "has to contain
valid date data" is a very convincing argument :)

Seems to me that what is and isn't a "valid date" varies a great deal
with the particular application.  For example, a value of
d'1742-11-05' isn't a valid date in ANY of my applications! Yet, the
date data type has no problem with it.

Sometimes the values of all zeros, or all nines are used as "special
values" which necessary in some applications -- but not possible with
the date data type.  I don't like using 0001-01-01 or 9999-12-31 as
special values for the simple reason that they ARE valid dates!!  I
don't WANT my special values to be valid dates!

If you're REALLY worried about the validity of the date, use a trigger
to validate it.  This'll give you the ability to do a more application
specific checking...

To me, the big advantage of date data types is that they make
programming easier.  Converting to a different date format or doing
things like ADDDUR SUBDUR, etc is a whole lot easier with the date
data type.   Imagine an international application that needs to
display dates differently for each country that the software is used
in... MUCH easier with the date data type.

If I had designed date data types, I would've allowed the zeros and
nines as "special values".  I would've also made "DATE" a keyword
that could be placed in the DDS of a file to explain that existing
numeric or character fields (without changing the layout of the
record) are dates.   Then things like logical files, SQL, OPNQRYF,
etc could use them as dates -- fixing a lot of Y2K problems very
easily.  Then, if this support was extended so you could just
recompile RPG programs to make them view these fields as dates...
wow...  would that have made Y2K easy.

But, I got the impression that the "correctness" of the Date data
type was more important than the amount of work it'd save people.
and THAT is what I really dislike about the date data type.

I also have programs written in RPG II, RPG III, OCL, CL etc. that
need to be able to handle dates that come from my files.  If I use
the date data type, I wont be able to use them everywhere... that'd
be even worse if I tried to use nulls...

So, yeah, date data types are nice.  But, they could've been better.


Jon.Paris@halinfo.it wrote:
>
>  >> Nothing wrong with numeric dates.
>
> Well there's one very obvious problem.  There's no way to ensure tha
>  you won't
> get an invalid date stored in your database if you are using numeric
>   For
> instance 00/00/00 <grin>
>

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.