<on-box>
I've said it before and I'll say it again (and I have not read all
thread-entries, so someone else might have said it as well): an 8
position decimal field is no date, it is an 8 position decimal field and
nothing else. It can contain values ranging from a very low minus value
to a very high positive value and those values have nothing to do with
dates. There is not much variation in representation other than on
display or printer with decimal periods or commas but which ever way it
is presented, it has the same decimal value. Mathematics is limited to
regular numerical additions, multiplications, subtractions etc., which
influences the figures in the decimal value by regular rules of the
decimal number system with overflows on values of 10 or multiplications
(by 10) thereof etc.
A date field is a date field containing (surprise, surprise) dates, at
least at the using end of the equation it is a very real date with days,
months and year values which are guaranteed valid (or either one of the
constants *LOVAL or *HIVAL). Values will never be less than zero (due to
the fact that day or month -1 don't exist) and the way it is represented
can vary (*ISO, *EUR, *USA, etc.) which either shows the year, month or
day part first, but whichever way it is presented, it is always
represents the same value. Mathematics is date mathematics, so you add
(or subtract) days, months or years or calculate differences between
dates and the overflow rules are too complicated to explain in one
sentence.
What you are asking is: can you store icecubes in an oven? You can do
it, but whatever comes out of the oven, it certainly isn't guaranteed to
be icecubes.
The first benefit of the date field is valid, because both sides of the
universe use the field for what it is made for: a date. The date is the
interface, the contract between both parties with predetermined meanings
and values. As long as both sides keep to the contract, all will be
well.
The second benefit of the date field is moot: there is no use of having
a date field without some means of manipulating it (or reading it). The
BIFS without date-fields have no meaning; they need eachother.
The first benefit of the decimal 8 is no benefit... the decimal contains
a value... is that a benefit? No it is the function of a decimal 8
field, it is its purpose, its reason for being, its.... well, you get
what I mean..
The second benefit of the decimal 8 isn't valid. You can't use date BIFS
on an 8 decimal field, you will have to tell the BIF that the 8 decimal
field isn't an 8 decimal field but some value which happens (by way of
miracle)to be representing a date and you will have to code a whole lot
of checking and errormonitoring around it.
</on-box>
Phew
Cor
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Mike
Sent: donderdag 13 december 2007 20:54
To: RPG programming on the AS400 / iSeries
Subject: To Date or Not to Date... that is the question
I go back and forth on this internally and decided to ask the experts.
Without starting another political battle (like that won't happen), when
defining a date field, is it better to define it as a date or as a
decimal 8?
What I see is:
Benefits to date:
* SQL selections on date are simple
* can easily use data BIFS
Benefits to decimal 8:
* Can have a "zero" date, a date typed field needs to be 0001-01-01
* date BIFS a bit harder to use (but not much)
What is your preference and why?
--
Mike Wills
http://www.linkedin.com/in/mikewills
Blog -
http://mikewills.name
Podcasts -
http://podcastmike.com
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
midrange.com
