× 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: AS400 Date Window For *MDY
  • From: "John Taylor" <john.taylor@xxxxxxxxxxxxxxx>
  • Date: Fri, 15 Oct 1999 18:48:42 -0600
  • Importance: Normal

Hi Jim,

Comments are inline.

> -----Original Message-----
> From: owner-midrange-l@midrange.com
> [mailto:owner-midrange-l@midrange.com]On Behalf Of Jim Langston
> Sent: Friday, October 15, 1999 4:53 PM
> To: MIDRANGE-L@midrange.com
> Subject: Re: AS400 Date Window For *MDY
>
>
> The fact is the "standard" on AS/400's is to use IBM's date
> field.  With the
> unwritten understanding that our logic should still work as long
> as we don't
> do anything "tricky" with it.  Put in a date and do simple math
> and functions
> on it and it becomes a black box.


Maybe my memory is failing, but I don't remember having date fields in the
database or RPG until V3R1 or V3R2. They weren't supported in display or
printer files until V4R3 or R4. I think it's a bit of a stretch to say that
the date data type is a standard in the AS/400 community. I think you'll
find many more instances of the date being defined as character or numeric.


> Being a black box, it makes absolutely no difference to us how IBM stores
> it.  IBM could decide to store it as the # of days since 010101
> if they wanted
> to and, in theory, our programs would still work.  If the OS
> stores a date as
> 32134 or 38291032 doesn't matter to me, as long as when I call
> for the date
> I get the same date that was entered originally.

Agreed. I don't have an issue with how IBM stores dates internally.

> When 2040 approaches, and IBM changes their OS to store dates differently,
> and they convert dates to the new method however they wish to do
> it (perhaps
> on the OS upgrade) my programs should still work, right?

Well, maybe. The problem is that you're making an assumption that IBM will
do this. This is what I would expect them to do as well. However, the reason
that I started the thread was to find out whether they will, or won't. As
currently documented, and generally acknowledged, the 6 digit date data type
will ONLY represent 01/01/1940 through 12/31/2039. It is a fixed window.

What if they DON'T change the range? Or, more likely, CAN'T change it
because the installed base has created applications that depend on the
existing behaviour?

I think we agree on how it SHOULD work, but everything I've seen in the
documentation indicates otherwise. Based on this, I'm going to avoid using
the date data type for 6 digit formats. A true shame, because they are
really handy when used for displays and printer files.


John Taylor


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-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:
Replies:

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.