FactoryLink ECS 6.5.0 Date / Time Bug


Thread Starter

Ranjan Acharya

Dear List, We have two customers with a bug in FactoryLink ECS 6.5.0. The FactoryLink clock does not correctly recognise the North American spring-ahead time change that occurred on 2001-04-01, i.e., EST to EDT. The FactoryLink clock is one hour behind (even though the underlying Windows NT PC clock is correct). The temporary workaround is to set the PC's clock one hour ahead. This is not a satisfactory fix, since other applications on the PC may be out of synchronisation and also the bug disappears sooner or later, at which time the clock must be reset. We have customers who have critical systems that require an accurate SCADA clock for data logging and alarm logging to name but two. I think that going into each application and hacking the date / time handling is not a good solution. Is anyone out there a big enough end-user of FactoryLink ECS 6.5.0 to lean on USData to provide a free patch? Does anyone else have a suggestion for an elegant solution with little or no overhead that means I do not have to modify the FactoryLink applications? The solution must not interfere with other programmes' access to the PC clock. Apparently USData does not support version 6.5.0. Their "patch" at this time is to upgrade to 6.6.0 (or 7.0 for that matter). The upgrade to 6.6.0 is free for customers with a support agreement. However, systems would have to be re-validated with a version change. Regards RJ

John G. Boland

Hello, the list, This sound suspiciously like the "April Fool's Bug" as described at: http://www.msnbc.com/news/553555.asp?0nm=T22B http://www.msnbc.com/news/551861.asp "...It's a quirky bug. Basically, some Windows-based programs become confused when Daylight Saving Time kicks off on April 1, creating an accidental April Fool's joke. For the following week, all software impacted will be one hour behind the correct time. On Sunday April 8, the problem corrects itself... "..The source of the problem is the way certain programs figure out what time it is. Programmers can choose to have their software ask the computer's operating system for the time, or they can ask other software to compute the time. If the program was written in using Microsoft's Visual C++, the programmer might have employed the time function in the Visual C++ Runtime Library - and that's where the bug is..." It's not much consolation, but a lot of Microsoft shops began having fun on early 1 April. Supposedly, the problem does not occur with Visual Basic. Go figure. One company told me that they traced this to "an older version of" msvcrt.dll. I can hear the operating system flames roaring to life again... Regards, John G. Boland, president VisiBit Corporation www.visibit.com One Parker Square Suite 408 2525 Kell Boulevard Wichita Falls, Texas 76308 940.322.9922 940.723.1478 fax

Ranjan Acharya

Regarding the 2001-04-01 to 2001-04-08 bug caused by incomplete testing of the underlying Visual C++ compiler. Note that this also makes the Y2K testing done on many of these systems look a little bit incomplete. Time change dates should have been checked too perhaps. At this time, it would appear that the problem with FL ECS 6.5.0 will correct itself on 2001-04-08. Not much consolation for users with critical systems. By the time they get any semblance of an upgrade programme, the problem will have disappeared until the time changes on 20XX-04-01 again. We will be into the FactoryLink internal second timer (32-bit SECTIME from 1980-01-01 00:00:00) rollover by then -- it rolls over in 2048-01-19 or so. Hopefully we will have all upgraded by then. RJ

Leon Ejdelman

We have determined that it is not only FL6.5.0 that is affected by this TIME BUG. In FL6.6 the standard tasks (GRAPH, ALOG,...) are OK. However, the POWER SPC, Compiled Math & Logic (which uses the C++ library) are NOT OK. The simple fix : 1- Double click on the desktop clock 2- Select "Time Zone" 3- Uncheck "Automatically adjust clock for daylight saving changes" 4- Adjust Clock The time will have to be changed next fall. leon ejdelman [email protected] www.letico.com

Torulf Wiberg

When I see the instruction above, a question comes to mind: How do you people who run your systems with daylight savings enabled handle the discontinuities that (according to my understanding) must appear in the history database ? What measures do you take to be able to get sensible information in your trend diagrams (as an example) ? /T ------------------------------------------------------- Torulf Wiberg Tel. +46 (0)411 533 110 Deterministic Control AB Fax +46 (0)703 83 08 08 Karl Kulls v=E4g 6 Mob. +46 (0)70 595 09 97 SE-274 56 Abbek=E5s SWEDEN