A little light humour

[Nick]

https://en.wikipedia.org/wiki/Year_2038_problem

[jack]

On behalf of all those as ignorant as myself, why 2038?

Not that it matters to me. I’ll be 86 and probably past caring!

Unix time is recorded as the number of seconds between a date and the Unix Epoch, 00:00:00 UTC on 1st Jan 1970. Being defined as UTC is very important, but that is a separate discussion. This information is stored in a structure called "time_t"

On nearly all older Unix programs, time_t is a signed 32 bit number. i.e. there's a range of -2147483648 (-2^31) to 2147483647 (2^31-1) seconds that can be stored before you add or subtract 1 and it over/underflows back to 0.

The total date range available around 1st January 1970 is 13th December 1901 at 20:45:52 UTC to Tuesday 19th January 2038 at 03:14:07 UTC (just over a 136 year span).

At this time, countless millions of older Unix programs will cease to work correctly. It's serious as these systems run pretty much everything these days and a lot of these systems are embedded and not easy to update. Indeed, many devices will simply be rendered useless as they are either incapable of being updated or it'll be uneconomical to do the s/w changes and updates.

The answer is to move to a 64bit counter. More modern 64bit Unix systems use a 64bit time_t which does not have the 2038 problem. Indeed, more modern C standard libraries use a 64bit time_t already, so even if the hardware is not 64bit, your new programs will not necessarily exhibit this issue.

Retrofitting a 64bit time_t into an older system designed around a 32bit time_t will be distinctly non-trivial in many cases, so there's really no easy solution for a huge number of use cases.

[Ant]

What sort of systems would be in use that would be 32 bit?
Would these be older legacy systems or relatively new ones?
Most companies i have worked for that had proprietary internal systems used unix based systems so i assume its more of an issue for those companies

[jack]

Simpler to just refer folk to https://en.m.wikipedia.org/wiki/Year_2038_problem

It's potentially a big problem as Unix is used in a lot of safety critical systems and frankly, a lot of users may unaware that kit is actually controlled by embedded Unix. Database field sizes are another potential failure mode.

[Nick]

It's not just *nix systems. There are countless embedded systems that are based on the C std library that used a 32 bit time_t. Cars, washing machines, routers just about everything that has more complex code than a bit of assembler. Of course they may not fail as they don't care about the date.

My last 3 series BMW (E90) had a similar problem. The millage had got so high a value wrapped around and it was Impossible to reset the service light.

[pre65]

The clock in the radio/sat nav unit on my Honda CRV went AWOL last year, and that was supposed to be due to some code in one of the chips.

Someone on the net predicted it would come back to life at a certain date in time, and blow me, it did. It was gone for about 9 months.

[jack]

Over/underflow of counters has been a traditional s/w failure mode for ever.

[shane]

Thanks for the explanation chaps.

Apparently the Kennel Club has a novel variant of this problem. If you wish to register your pooch as Champion Snodgrass Snuffles the 37th, that’s absolutely fine, but you’ll have to think of a new name for his successor. This came up as an issue a while ago. Reason? The number is entered on their database in Roman numerals in a field which can accept up to six characters. 37 is XXXVII but 38 is XXXVIII, the lowest Roman numeral with seven characters. This is apparently an insuperable problem, but I suspect not on the same scale as the 2038 issue.

[Dave the bass]

Well, 'we' might be getting some help to solve all these-sort-of-problems, for it is written (and sang) that in the year 2032 Planet Gong will make contact with Planet Earth.

That'd be handy.

And whahey!

[Mike H]

Fascinating all!

I was going to say, 'What have I started now ...'

Anyhoo, the next one I fancied posting was this .....
-

When a tree falls SS.jpg (25.19 KiB) Viewed 11069 times

[brig001]

I love the fact that time_t is a signed 32 bit number. Who thought, you know, we might get time travel in the future, so signed it is

[Nick]

I love the fact that time_t is a signed 32 bit number. Who thought, you know, we might get time travel in the future, so signed it is

Its almost as if there were things in the past that happened before 1970.

[Nick]

Fun fact that happened yesterday, that shows how these sorts of errors creep in. I decided to change the code in my turntable supply that generates AC mains replacement at 50, 60, 67.5 and 81Hz for UK and US 33 and 45 RPM operation. Instead of jumping from (say) 50Hz to 67.5Hz when the speed was changed, I thought it would be good if the speed changed between those points smoothly over a couple of seconds to prevent the motor stalling. So I coded this and it was working fine. But I realized that when going from 67.5Hz to 50Hz, the voltage was too high once it left 67.5Hz, becoming correct again when it reaches 50Hz. I have a lookup table that relates to the system gain against frequency, 1.0 at 50Hz, 0.9 at 60Hz, 0.85 at 67.5Hz, that sort of thing. Because the frequency now was not only at those 4 known values, the lookup table was not a valid solution. So that was the first problem that might have gone unnoticed. To solve this I used the original table points to create a polynomial to generate a gain value at any frequency that matches the points in the table. That worked great, all looking good. Then I thought, I may as well add the +- 3Hz adjustment to the value passed to the polynomial function to keep the output voltage constant with those small changed. That too worked well, until I tried reducing the frequency to 48Hz, that caused the poly function to return a value > 1 which then started to make the DAC move into its non linear area (Atmel DAC's are not linear near the rails so you have to cope with dead bands near the lowest and highest range). Only noticed this on the scope as the sine started to go odd as I lowered the frequency.

Just an example how small, safe seeming changes can come around to bite you.

[jack]

The point about not being just Unix systems is important.

This is really an issue of the CRTL - the C programming language run time library.

This library is used by anything programmed in C; not just Unix, but including OS-free environments such as microcontrollers. So any system programmed in C is potentially vulnerable and there are probably billions of those, from central heating controllers to ovens, to TVs, to toasters, to telescope tracking, to air traffic control systems.

[Ant]

An eagle may soar, but weasels dont get sucked into jet engines