UK: tests show that the date February 29 may cause more disruption than January 1.

greenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread

Excerpt from the story in The Journal

Leap year sets up a new hurdle for SMEs - Millennium bug could bite on February 29 by Rik Kendall

JUST as businesses are beginning to think the millennium bug had been squashed another infestation could be looming on the horizon. Despite many commentators now claiming the fear and hype was unwarranted and costly, warnings are being directed at small businesses in the North-East about leap year 2000 when computers may not recognise February 29 as a date.

The Association of Chartered Certified Accountants (ACCA) stresses this potential computer hitch could put the bite back in the millennium bug.

David Harvey, head of ACCA's small business unit, explained: "There is a danger in writing Y2K issues off as the century's biggest scam, but it is likely many bug related problems have yet to surface." Some tests show that the date February 29 - 2000 being a leap year - may cause more disruption than January 1.

Linkt to story:

http://www.the-journal.co.uk/cfm/busistory.cfm?StoryId=161610

-- Carl Jenkins (Somewherepress@aol.com), January 18, 2000

Answers

I don't buy it. This is simple compared to y2k. No system changes are need (i.e. update years add 500000 or expand the databases to hold 2 extra digits). If a problem does surface in my code, it would be just a quick change to one of my subroutines. Because this handling is done in one subroutine call.

-- Larry (cobol.programmer@usa.net), January 18, 2000.

Anything will cause more problems than Jan1,2000 He he he he.

Actually the IT's were probably to stupid to know about the no leapyear rule on the 100 years, so they ended up doing the 400 year rule by default!

-- Cherri (sams@brigadoon.com), January 18, 2000.


he he he, just like Cherri is too stupid to know how to spel two, to too.

-- (-@-.-), January 18, 2000.

I agree, it is not a problem of you have made the fixes ahead of time, but there are still alot of people out there who are planning on fixing on failure or who don't realize that additional fixes are needed.

It is interesting to note that John Koskinen apparently does not think that the leap year date conversion problem is a non-problem. He has point out more than once since January 1 that his office has discovered that alot of people had not corrected for the February 29 date and that they need to do that. The ICC is going to be closely monitoring what happens around that time frame. (I hope they are also getting the word out that the date conversion correction needs to be in advance.)

Some questions concerning those who fail to make the corrections:

1) If two data sets are interfacing and one thinks it is one date and the other another date, you have problems....right?

2) Won't problems be created if an embedded system that is integrated with software that thinks it is March 1 when it is actually February 29?

3) What if a chemical processing plant has numerous embedded systems, some of which are integrated with software that has been corrected for the leap year change and some of which are integrated with software that has not been corrected?

4) What if you throw into the mix some systems that were correctly remediated for Y2K with some systems that were not remediated? and what happens when you have a situation where both the date conversion problem and the Y2K rollover problem come into play at the same time?

Can anyone shed light on these questions?

Thanks!

-- leapyear (leapyear@is coming.help), January 18, 2000.


http://hv.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=001wHU

[snip]

New Computer Bomb Emerges on Feb. 29 for Leap-Year Adjustment

Source: Jiji Press English News Service

Tokyo, Dec. 4 (Jiji Press)--While most major companies have finished defusing the millennium computer bomb, a new bug is emerging as a potential hazard to computers as some software programs might not be able to recognize Feb. 29, 2000, properly.

The new glitch, linked to leap-year adjustment functions, could throw Japan's banking system into disarray as settlement programs may malfunction to set off a chain of defaults, experts warn.

A leap year comes every four years, with the exception of years that are divisible by 100, when February has 28 days just like other normal years.

Years divisible by 400, however, are leap years whose February has 29 days.

This complicated calendar system burdens computer programs with a cumbersome task of distinguishing quadricentennial leap years from centennial normal years.

Computers ill-prepared for this leap-year intricacy may misinterpret the year 2000, which is divisible by 400, as a normal year with 28 days in February and fail to recognize Feb. 29, experts say.

To make matters worse, most corporate fund settlements fall on the last business day of each month, with actual payments due a month later.

In 2000, Feb. 29, which falls on Tuesday, will thus be the first payment date for most corporate transactions and that worries many company executives.

A senior official of a leading chemical maker said if the leap- year computer bug should disrupt the company's settlements, that would be a major blow to clients' confidence in the firm's creditworthiness.

In an attempt to avert a possible disaster on Feb. 29, Japan's major automakers have decided to move up the settlement date for their group accounts to Feb. 28.

Many companies in other sectors are expected to follow suit as anxiety about the leap-year glitch keeps the business community on its toes well into the new millennium, observers say.

Publication date: Dec 04, 1999
) 1999, NewsReal, Inc.

----------------------------------------------------------------------

[snip]



-- Linkmeister (link@librarian.edu), January 18, 2000.



More bullshit, Feb 29 will come and go without a problem, however it doesn't surprise me that people are still milking this non issue.

-- Mr. Sane (hhh@home.com), January 18, 2000.

February 29 will not be as innocent as some people make it sound, and it will compound the original January 1 problem.

Take care

-- George (jvilches@sminter.com.ar), January 18, 2000.


Mr. Sane,

If you absolutely, positively know for a fact that February 29th is a non-issue, then contact your Congressmen (if you're an American) and tell them to shut down the Y2K Information Coordination Center:

http://hv.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=001mUs

[snip]

Round-the-clock operations would continue into the first few days of January, ``or longer if conditions warrant,'' a fact sheet said.

The ICC will wind down in March after keeping tabs on automated systems through Feb. 29, a Leap Year day that could also trip unprepared computers.

[snip]

There's still time for organizations (like Japan's automakers) to either fix any problems or to make contingency plans.

-- Linkmeister (link@librarian.edu), January 18, 2000.


Mr Sane:

I am certainly glad you are such an expert here, during the plant where I work pre rollover testing, January was no problemo, the only problems were Feb leap year. HHhhhhhmmmmm. But of course we are the only operation that uses computers so surely nobody else will see this.

-- Squid (ItsDark@down.here), January 18, 2000.


I do not know if anyone has mentioned this yet. I have little time this evenning, but here is a thought. If clocks were sent back in time, the last year which was a leap year and which had Jan 1 as a Saturday was 1972 (?). Now, since no computers could actually be set to that date (?), then plant managers anc accountants may have reset the date to the last one on which Jan 1 fell on a Saturdsay. This will not be a leap year, so processes might skip directly to March 1 rather than go through the yeap year day Feb 29. Alternatively, they might execute month-end procedures on 2/28.

If this scenario is possible , then there could be some interesting consequences to 2/29/2000. Skipping the month-end, or executing it one day early, is not a pretty sight.

Does this rambling post make any sense to anyone else? Has this topic been convered already?

Wondering,

-- Uhhmmm... (JFCP81A@aol.com), January 18, 2000.



Wondering, I don't think so. I've been following up on the February 29 issue on a couple of other threads and no one has presented your case against back-dating, which seems reasonable to me.

Take care

-- George (jvilches@sminter.com.ar), January 19, 2000.


So, I should stay in my bunker then?

Interesting speculation, but, er, so what? We're talking small widespread financial cost here, not loss of life or cascading effects.

-- Servant (public_service@yahoo.com), January 19, 2000.


Servant, once IT and non-IT systems start to screw up big time, you would rather be safe than sorry, right? Feb.29 problems would just compound on top of Jan. 1 rollover problems which haven't yet picked up cruising speed, right? . Would it still be manageable? World-wide? Let's at least give it some thought, don't you think?

Take care

-- George (jvilches@sminter.com.ar), January 19, 2000.


Moderation questions? read the FAQ