Hi all,
if im right its necessary to change all my cgis and change the 1900 to 2000. Ok, so far.
In Links 1.11 there are 3 times the 1900. But at one point there´s a message from Alex ... y2 compliance ... so what i want to know is where should i change where not.
The same to Links 2.0

Robert

nope.. perl is not affected by y2k..

i believe perl is affected by y2k26 or something

alot of people think the 1900 gets messed after y2k.. (i did a few weeks ago).. but it doesn't..

jerry

Im not afraid of affecting perl. I think there is a sub used in almost every perl-script; it takes the date in 2 digits and adds 1900 for the output. So after newyear it will show 1900 for the date (1900+00) instead 2000+00.
Cause of finding this only 3 times in sql 1.11 and think that mysql was y2c i let it till 2000 and will see what happen.

I have set all to 1618! Nice year here in germany.
:-)

no..

after new years..

instead of

1900+00

it will be 1900+100

i never knew this until a few weeks ago..

it's cause localtime's value for the year is 99.. since localtime is an array it doesn't matter if it's 2 digit or 3 digit.. but i don't know what's up with the y2k26.. probably cause of the time() function adding another digit?

jerry

if you want to be the only one using links sql with the wrong date.. i don't mind.. go ahead and do it ..

jerry

It's worth checking your perl scripts. A lot of people do have Y2K bugs in their CGI scripts (in fact this forum has Y2K bugs in it).

Where you see a call to localtime, look at how the year is handled. localtime returns the number of years since 1900. So in 1990 it would return 90, in 1999 it would return 99, in 2000 it will return 100, in 2005, it will return 105. So to get a proper four digit year, you need to add 1900 to the value. To get a proper two digit year, you should add 1900 and then drop the first two digits.

Hope this helps,

Alex

Alex,

Are you going to update the forum to work around that bug then? You have 6 hours (Aussie Time) - Which is about 23 hours PST or something, so you better get your act on

i think alex is saying the y2k bug will make the years 19100

??

jerry

Post-Y2K report on Links in Denmark: It's working, don't worry, be happy :-)

HAPPY NEW MILLENNIUM!

See date at http://www.gotzespace.dk/links/

No.... what Alex is saying is if you try to get a 2 digit year, the only RELIABLE way is to go through the full process of adding 1900 to the 2 or 3-digit year, then dropping the first two digits.

You can alternatively use the LAST TWO digits to get a two digit year, but the problem with any short cuts is that at some point you will be bitten by it.

THe formula is "years since 1900, so the year 2000 is 100 years from 1900, and the localtime function returns 100 -- to make that a REAL year, add 1900 to it, and you get 2000

One thousand years from now, the year will be reported as 1100, and the only way to make sure you get a good year is to add 1900 to it, get 3000 and drop the first two digits to get '00'

You can't assume that the year is going to be 2 or 3 digits... it can be both.

That's all.... The Y2K problem is that you can no longer assume a 2 digit return value from localtime.... it may be 3 digits.

Not an SQL question, but it seems related to the thread. This is strange... I'm going to have to do some looking around Links and find the localtime calculations. The glitches I've notice are:

1) All the categories on the home page have the 1-2 days new image (using three levels of new graphics), but not all of them really have new links contained within.

2) All search results come back with the 1-2 days new image.

3) In admin, add a link places "1-Jan-1910" as the date.

4) Last night's cron build (4 am server time) did not build an index page for the "new" directory, and as you can see (unless I fix it first):

www.run-down.com/New/

there is a page for seemingly every day of new links going back to April '99, which would be right around when I installed the script.

Time to start digging...

Dan

edit: Further info, nph-build.cgi is flagging every link as new (explains #2), building the homepage (explains #1), and dying after the new build because it can't find the "new" index page. That's why none of the category pages show "new" -- they haven't been updated.

nph-build.cgi uses time(); throughout, but I don't see any mention of localtime in it. Seems to only show up in db_utils.pl and links.cfg, and nothing looks out of place that I can see...

edit2: As noted in http://www.gossamer-threads.com/...m12/HTML/001802.html the problem was not script-related. Sorry.



[This message has been edited by Dan Kaplan (edited January 01, 2000).]

[This message has been edited by Dan Kaplan (edited January 01, 2000).]

An example:

My logs rolled over this morning, and my access_99-12-31 file was followed by an access_100-01-01 file.

Great for numerical sorting, but a bit hard on the brain when looking at years..



[This message has been edited by pugdog (edited January 01, 2000).]

if you guys wait some time.. probably (whatever days your new thing is) then it will clear up..

jerry

Court TV's TV listings showed today as:

>> Sunday, January 2, 19100

That's what I mean about taking short cuts