YEAR 2000 bug 
Author Message
 YEAR 2000 bug

I suppose that this question has probably been responded before but as
I have not followed the development in Clipper for some years I don't
know if  there is an answer.

For my work, I use an application that I have writed ten years ago in
Summer 87.  This application use the date fields to calculate how old
are my clients. As the date field in Summer 87 are 8 caracters with 2
for the years, I suppose that in year 2000, it,s will be the beginning
of the trouble.

Does there is a solution to this problem?

Thanks

Francois



Sun, 15 Oct 2000 03:00:00 GMT  
 YEAR 2000 bug

On Wed, 29 Apr 1998 01:28:38 GMT, Dave Pearson

Quote:

>The other option is to change the EPOCH for your application. Clipper 5.0
>has the SET EPOCH command for doing thing, S87 lacks it. However, IIRC
>someone has come up with a EPOCH hack for S87, I don't have the details to
>hand, but a quick search on DejaNews should locate the information for you.

I'm confident that it is on the Oasis, somewhere in the general or lib
section.

Quote:

>Also, check out this URL:

>      http://www.iag.net/~philb/clipy2k.htm

>--
>Take a look in Hagbard's World: |     w3ng - The WWW Norton Guide reader.
>http://www.acemake.com/hagbard/ |  ng2html - The NG to HTML converter.
>http://www.hagbard.demon.co.uk/ |       eg - Norton Guide reader for Linux.
>Free software, including........|   dgscan - DGROUP scanner for Clipper.

Wim Kok



Sun, 15 Oct 2000 03:00:00 GMT  
 YEAR 2000 bug

I'm using S87 and this is what I've done:

Alot of my apps only show and print the date as held in the dbf. If the user
enters
01/15/03 then the computer stores it as 1903. But that's ok because when it
prints  the date it still prints 01/15/03 and it will appear to be 2003.

For the date fields that can potentially be used for calculations, such as
invoice date, after reading the date from the user I have the following

Read
If YEAR(InvoiceDate)<1980
   InvoiceDate = InvoiceDate + 36525
Endif

Also, I have found that for a pc that will keep the proper date after Y2K, then
Clipper responds to the DATE() function properly...

Does anyone see any problems with this logic????

Thanks,
Fred Zuckerman
San Diego, CA, USA



Sun, 15 Oct 2000 03:00:00 GMT  
 YEAR 2000 bug

Quote:
>I'm using S87 and this is what I've done:

>Alot of my apps only show and print the date as held in the dbf. If the user
>enters
>01/15/03 then the computer stores it as 1903. But that's ok because when it
>prints  the date it still prints 01/15/03 and it will appear to be 2003.

>For the date fields that can potentially be used for calculations, such as
>invoice date, after reading the date from the user I have the following
>snippet:

>Read
>If YEAR(InvoiceDate)<1980
>   InvoiceDate = InvoiceDate + 36525
>Endif

>Also, I have found that for a pc that will keep the proper date after Y2K,
>then
>Clipper responds to the DATE() function properly...

>Does anyone see any problems with this logic????

>Thanks,
>Fred Zuckerman
>San Diego, CA, USA

I see one tiny little problem with the logic, although it's not necessarily the
program logic itself.  In upgrading S87 Clipper code, I thought it out and came
to the conclusion that it's far better to modify the picture statements in my
code than it is to save potentially erroneous date data and write calculations
(or call functions that do the calculations) to correct for possible problems.
If your code makes extensive use of picture clauses in GETs and SAYs, they're
easy to find, easy to fix, the users will get used to entering a 4-character
year, and your data will be accurate.  Just my preference.




Sun, 15 Oct 2000 03:00:00 GMT  
 YEAR 2000 bug


Quote:
>A lot of my apps only show and print the date as held in the dbf. If the user
>enters 01/15/03 then the computer stores it as 1903. But that's ok because when it
>prints the date it still prints 01/15/03 and it will appear to be 2003.

Yes, but if you have any date indexes, they will sort improperly. Do
you have any reports that print by date range? Broken.

Quote:
>For the date fields that can potentially be used for calculations, such as
>invoice date, after reading the date from the user I have the following
>snippet:

>Read
>If YEAR(InvoiceDate)<1980
>   InvoiceDate = InvoiceDate + 36525
>Endif

This won't work after Feb 28, 2000, since 2000 is a leap year and 1900
is not, leaving your formula one day off. It will also always
calculate the day of week improperly, even if you correct that offset.
Day of Week repeats every 28 years until 2100.

Better to use the Epoch function for S'87 available on my www site.

Quote:
>Also, I have found that for a pc that will keep the proper date after Y2K, then
>Clipper responds to the DATE() function properly...

Yup.

Quote:
>Does anyone see any problems with this logic?

Well, Fred, if it were me, I'd catch those input dates and correct
them before storing them. After doing that, everything works pretty
much as expected.

There is some patch code on my www site that addresses this and other
problems. Also, read the links on my y2k link page.

--

        Oasis WWW  http://www.iag.net/~philb/
 Oasis WWW Mirror  http://www.enterconnex.com/oasis/
         FTP Site  ftp://ftp.iag.net/pub/clipper

      Everything that is really great and inspiring is
      created by individuals who can labor in freedom.

                                     Albert Einstein



Mon, 16 Oct 2000 03:00:00 GMT  
 YEAR 2000 bug

[snip 2-digit year problem]

Quote:
> Dear Fred,

> Yes there will be one big problem.

> Please try to enter 29 february 2000 as  02/29/00. This date exists, only
> Clipper will respond with a illegal date, becourse 29 febraury 1900 does not
> exists. So 2000 is not the real problem with s87. The fact that 2000 is a
> leap year and 1900 wasn't is the problem child. If you are not planning to
> change from a MM/DD/YY to a MM/DD/YYYY notation, you have to trap this
> problem with a function in the GET-statement. This function must change the
> 02/29/00 (1900) entry internal to 02/29/00 (2000), before clipper reads the
> date and response with the error.

> Something like this:


> read

> ****
> function DGET

> parameter dDatum

> xDag  = Day(dDatum)
> xMaand= Month(dDatum)
> xJaar = Year(dDatum)
> if xJaar < 1950
>    xJaar = xJaar +100
> endif
> xString = str(xDag,2)+"/"+str(xMaand,2)+"/"+str(xJaar,4)
> dDatum  = ctod(xString)
> etc etc etc (not ready)

> If anyone has a solution for this problem, please post it.

Rather too big to post, but I've sent some stuff to Phil B.
for him to evaluate with a view to making it generally avbl
on the Oasis.  The fix (if deemed OK) requires no source
change - only a "set epoch=nn" in the DOS environment and
a re-link with a replacement OBJ/LIB.

I just retested against 29 feb 2000 and it seems solid.
Phil is busy at the moment - please be patient...
--
Pete
        "We have not inherited the earth from our ancestors,
         we have borrowed it from our descendants."



Mon, 23 Oct 2000 03:00:00 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Advantage Database Server Year 2000 Bug

2. Year 2000 Bug

3. year 2000 bug

4. year 2000 bug in clock

5. year 2000 bug in Tcl!

6. Is year 2000 a leap year??

7. Extensive cobol year 2000 methodology by TOPIC-2000

8. Cobol year 2000 solutions by TOPIC 2000

9. Year 2000 Newsgroup

10. OS/390 Release 2 Year 2000 discussion

11. WWW.ANTIY2K.COM mainframe year 2000 solutions

12. Year 2000 IBM Asm370 Booming Job Market

 

 
Powered by phpBB® Forum Software