Significance of the year 2039 under OS/400
The AS400 User
Can't the IBM iSeries handle dates after 2039?
I have been asked to convert all my 12/31/2199 (originating from a DB) to
12/31/2039 for use by COBOL / RPG programmers on our AS/400
Thanks!
Ken
On 01 Mar 2004 01:11:44 GMT, the40...@aol.communist (The AS400 User)
wrote:
>What exactly is the significance of the date 31 December 2039 on the AS/400?
>Can't the IBM iSeries handle dates after 2039?
1940 to 2039 is the range that can be expressed with a two-digit year.
See
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/c092508415.htm#HDRDDATE
--
Ken
http://www.ke9nr.net/
Opinions expressed are my own and do not necessarily represent the views of my employer or anyone in their right mind.
Bradley V. Stone
Y2K had some glitches, but not many. More hype than anything.
Now, if the media can actually grasp the concept of why 2039 will be
worse than Y2K, then you can see programmers will get an even worse wrap
for bandaiding Y2K to get by for 39 more years. :)
By checking the last 2 digits of the year (or the "only two in these
cases") if it's 39 or lower, it's 20xx.. if it's 40 or greater, its 19xx.
Not sure if this is who IBM did their dates, but I believe at first it
was that way. I would assume it is fixed by now or will be sometime in
late 2039. ;)
Brad
www.bvstools.com
Jonathan Ball
It's IBM's choice of a "window" year, in order to use
two-digit years. Any two-digit year between 40 and 99
(inclusive) is presumed to be the 20th century, i.e.
1940-1999. Any two-digit year from 00 through 39 is
21st century, i.e. 2000-2039.
As far as I know, you only see it in things like the
use of two-digit years in search strings, etc.
Dan Hicks
The iSeries can handle dates out to something like 2065. The
internal clock counts in microseconds and is centered around Jan 1
2000, giving it a range of roughly 1935 to 2065. (Don't recall the
exact years, but it's roughly that.) However, different places in
the OS and application software handle dates differently.
--
Dan Hicks
In most things success depends on knowing how long it takes to succeed.
DBDriver
vendors might have their own different "windows" for each app. We used the
year "80" in one of ours about 10 years ago. We now force 4 digit years so
it is not a potential issue anymore.
By the way, this is not just an IBM thing. VB, for instance, also has a date
interpretation window for it's internal date conversion functions. When you
think about it, if 2 digit years are keyed then any application will have to
try to work out the intent of the user by some means.
RJ.
"Ken" <ng3122@ke9nr.#nospam#.net> wrote in message
news:vj6540lb6kias6tm9...@4ax.com...
Dave McKenzie
> The AS400 User wrote:
>> What exactly is the significance of the date 31 December 2039 on the
>> AS/400? Can't the IBM iSeries handle dates after 2039?
>>
>> I have been asked to convert all my 12/31/2199 (originating from a DB) to
>> 12/31/2039 for use by COBOL / RPG programmers on our AS/400
>
> The iSeries can handle dates out to something like 2065. The
> internal clock counts in microseconds and is centered around Jan 1
> 2000, giving it a range of roughly 1935 to 2065. (Don't recall the
> exact years, but it's roughly that.) However, different places in
> the OS and application software handle dates differently.
>
It's 1928 to 2071. Here's an interesting (& scary) page:
http://www.iee.org/Policy/Areas/SCS/problemdates.cfm
Notice that if you can get to 2101, you're home free (till 9999).
--Dave
Terence
2039 restiction is only if using the 2-digit year format.
the40...@aol.communist (The AS400 User) wrote in message news:<20040229201144...@mb-m05.aol.com>...
Terence
great-grandchildren can fix it by then. The AS/400 database, though,
can handle 0001 to 9999. I don't have any problem storing dates
before 1935 or after 2071.
Dave McKenzie <dav...@zbiggroup.com> wrote in message news:<1045e60...@corp.supernews.com>...
Gentleman
commenting on. I don't expect original poster to understand packed fields
but lets see if I can explain this. Some of this may be based on the
standards of the company I work for.
For many years our company used a 7 digit date with 0 decimals, by using an
odd sized date field and a Packed field type we were able to save both
storage and memory space and handle a 6 digit date stored in 4 character
spaces. I understand this same thing happened in many other companies so IBM
has this listed as an official solution. (It's too late for me to look up
where it is.)
Basically Packed fields break a standard character field into two characters
based on their hexidecimal values. so while a space is represented by Hex
'40' Packed fields specify that Hex '40' can also represent the number 40.
For example the date Oct 24, 1996 would look like this when viewed in Hex
Format '0961024F' The 'F' specifies that the number is a positive value.
This format is known as YYMMDD.
The new convention that is used by the 2039 window is refered to as the
Century byte so today's date (March 17,2004) would look like '1040317F'
Where the 1 simply represents the 21st century. This format is CYYMMDD. Some
IBM Manual somewhere has it specified that the Century byte can continue
through the number 9 so we are actually good for another 900 years.
Of course not all code will follow this convention exactly and may require
modification before 2039 in order to work correctly but the standard is
already in place.
Packed fields are a difficult concept for non iSeries programmers so if you
don't get it and have a specific question please feel free to contact me.
"The AS400 User" <the40...@aol.communist> wrote in message
news:20040229201144...@mb-m05.aol.com...