1. Home
  2. Electronics Design
  3. OT: An expensive software error, year 2010 bug: 240 Million Euro!
  4. Page 2

OT: An expensive software error, year 2010 bug: 240 Million Euro!

At one of my past jobs, we had a 'manufacturing day' calendar. Basically a 3 digit number than counted scheduled work days (Monday thru Friday, skipping holidays and contracted vacation days).

Our IT department had provided some library functions that would read a data file of vacations/holidays and convert from calendar dates to manufacturing day numbers (and back). Problem was, every time the union renegotiated work schedules or corporate added a holiday, IT would generate new data files and distribute them for installation on various systems .... if the new admins could remember where they put it the last time.

Some of us smelled disaster and rewrote the library functions (unauthorized by the IT department) to use the NIS client-server architecture to do the lookups from a central machine. But I never found out whether IT ever caught the clue before I left. I'm guessing that at some point, they'll find the one machine sitting in a data closet and, not being aware of what it does, unplug it. When I read a story about the plant shutting down due to an IT problem, I'll always wonder about this one.

--
Paul Hovnanian  paul@hovnanian.com
----------------------------------------------------------------------
Have gnu, will travel.
Reply to
Paul Hovnanian P.E.
Loading thread data ...

Which is reasonable enough; it's not uncommon to want to represent times in the past.

time_t is invariably a "long", i.e. it's 32 bits on 32-bit systems and

64 bits on 64-bit systems. I doubt that many 32-bit systems will still be in use in 2038; if they are, it can be changed to a "long long", which will cause a few compatibility headaches, but no more than using 64-bit file offsets (i.e. allowing files >2GiB).
Reply to
Nobody

On a sunny day (Sun, 10 Jan 2010 17:17:33 +0000) it happened Nobody wrote in :

Oh, I am sure they will! Lots of embedded stuff to start with. And that is where it will hit hardest, people will no longer be able to 'update firmware', as it is too old a model, so they need to buy new stuff. So nobody will do anything about it now, to guarantee sales tomorrow.

Example: Linksys routers on MIPS that run Linux, in many homes. OTOH they probably need to buy an IPV6 model before that... Or one with an optical interface...

In industrial applications it will create plenty of problems, and work before 2038 to 'fix' it I suppose.

Reply to
Jan Panteltje

'update firmware',

Do they even need to know the time? If they insist on a date, give them one a decade earlier. Problem solved.

Sylvia.

Reply to
Sylvia Else

Maybe it has something to do with BCD enconding? E.g. the card OS uses BCD for the date, which means it changes form 0x09 to 0x10, but the reader assumes a binary encoded format and thinks it is year 16 instead of 10. Would be a bit strange, because this would mean there is no century encoding or the card OS programmers are using really ugly hacks.

you insert them.

their own cards soon.

I don't think this is possible, because the communication should be encrypted. But in the light of how professional the OS card programmers are, maybe not. Maybe some known plaintext attacks are possible.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

Er, 2038 is a bit further away than "tomorrow". It's not as if anyone was worrying about the Y2K problem in 1972. And the life expectancy of technology is continually getting shorter.

Anything that needs to display or accept input from humans already needs to allow for updates in case of changes to DST rules.

Reply to
Nobody

It wouldn't surprise me if the digital data is more or less a copy of what's printed (well, embossed) on the card (sort code, card number, valid from, valid to, issue number, ...), with each decimal digit being stored in a nybble.

The valid from/to dates printed on the card don't have a century; given that cards intentionally have a lifespan of only a few years, there isn't really much need.

Reply to
Nobody

Or better, ignore them completely.

Reply to
krw

On a sunny day (Tue, 12 Jan 2010 02:50:30 +0000) it happened Nobody wrote in :

hehe, it is only 28 years out. Some here have done several of those terms.

But it was discussed in the eighties, I remember that.

You are absolutely right about that, pretty weird situation, look at the old TV system, then they kept it compatible with BW with NTSC, then now digital is hardly here and we have 3D digital... Years and years of CRT, then slowly LCD, now all of the sudden iink paper, Mirasol, O-LED, what not.

formatting link
Now there is a display technology that amazes me, dunno what is the future of that. No bets, but it could be revolutionary, as it is fast and uses power only when changing view. But that does not mean some things will not simply work 28 years later. My little 8052AH BASIC computer is from 1988, and it worked after I powered it up and even the Nicads charged after a few hours. RS232 is also still in use to communicate with it, as is i2c, so 21 years and going strong. Chips last ?forever?, well a long time, except perhaps for EPROM and EEPROM that loses data. Because of EEPROM much stuff the archaeologist find when they dig up electronics

1000 years from now will not do anything....

Not sure what you mean by that, Daylight Saving Time? I still have to adjust 10 clocks or so 2 times a years in my house.

Reply to
Jan Panteltje

be

to

was

Not true. Most banks and insurance companies held paper with 30, 40, 50 = year=20 or longer maturities. And by track record, had the least problems with = Y2K.

Reply to
JosephKK

BCD

  2. >> Would be a bit strange, because this would mean there is no century

valid

isn't

That still leads to the same specification error in the card/reader = software=20 interface.

Reply to
JosephKK

Yes.

Those probably aren't using Unix time. If the only keep the time and not the date, it's most likely just seconds since midnight.

Anything using Unix time and displaying it to the user is probably going to use local time rather than UTC, which means accounting for timezones and DST. Chances are, the DST rules will change before 2038, so if the firmware can't be updated, 2038 is the least of the problems.

If I was designing an embedded system now and there was a chance that it would need to still work in 2038, I'd probably just make time_t unsigned, adding another 68 years.

Reply to
Nobody

It should be noted that the DST rules may be different from country to country, so at least a device intended to be carried around should work properly.

Even if there are means of inputting rules for the DST changes, do all systems work properly in the Southern hemisphere, where the DST is used around new year.

Reply to
Paul Keinanen

On a sunny day (Sat, 16 Jan 2010 07:35:44 +0000) it happened Nobody wrote in :

My Linksys web server (modified WAP) runs UTC, the logs can be confusing as far as time goes.... It is 100% an embedded system. If it still works in 2038? I dunno, how long does FLASH last? :-)

Reply to
Jan Panteltje

There standards don't specify implementation details (e.g. the format of the rule files).

The GNU libc implementation is essentially an ordered array of pairs of a Unix time (seconds since the epoch) and a code. The code is an index into an array of local time classes, each of which defines an offset from UTC in seconds, whether it represents DST (for the tm_isdst field in "struct tm"), and a textual abbreviation. This allows for multiple types of DST, e.g. double daylight time.

So a zoneinfo file which provides rules for the next twenty years would have forty entries, with one for the start of DST each year and one for the end.

The zoneinfo file format is documented in the tzfile(5) manpage. Files can be dumped in a human-readable format with "zdump". The files are generated from a more structured format (e.g. "from 1970 to 2010, DST starts on the last Sunday of April") using "zic", whose manpage documents the format.

Reply to
Nobody

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.