A little light humour
#2671 Re: A little light humour
Whenever an honest man discovers that he's mistaken, he will either cease to be mistaken or he will cease to be honest.
- jack
- Thermionic Monk Status
- Posts: 5504
- Joined: Wed Dec 29, 2010 8:58 pm
- Location: ɐılɐɹʇsnɐ oʇ ƃuıʌoɯ ƃuıɹǝpısuoɔ
- Contact:
#2672 Re: A little light humour
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.
Vivitur ingenio, caetera mortis erunt
#2673 Re: A little light humour
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
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
- Thermionic Monk Status
- Posts: 5504
- Joined: Wed Dec 29, 2010 8:58 pm
- Location: ɐılɐɹʇsnɐ oʇ ƃuıʌoɯ ƃuıɹǝpısuoɔ
- Contact:
#2674 Re: A little light humour
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.
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.
Vivitur ingenio, caetera mortis erunt
#2675 Re: A little light humour
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.
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.
Whenever an honest man discovers that he's mistaken, he will either cease to be mistaken or he will cease to be honest.
- pre65
- Amstrad Tower of Power
- Posts: 21400
- Joined: Wed Aug 22, 2007 11:13 pm
- Location: North Essex/Suffolk border.
#2676 Re: A little light humour
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.
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.
The only thing necessary for the triumph of evil is for good men to do nothing.
Edmund Burke
G-Popz THE easy listening connoisseur. (Philip)
Edmund Burke
G-Popz THE easy listening connoisseur. (Philip)
- jack
- Thermionic Monk Status
- Posts: 5504
- Joined: Wed Dec 29, 2010 8:58 pm
- Location: ɐılɐɹʇsnɐ oʇ ƃuıʌoɯ ƃuıɹǝpısuoɔ
- Contact:
#2677 Re: A little light humour
Over/underflow of counters has been a traditional s/w failure mode for ever.
Vivitur ingenio, caetera mortis erunt
- shane
- Social outcast
- Posts: 3405
- Joined: Sun Sep 16, 2007 12:09 pm
- Location: Kept in a cool dry place.
#2678 Re: A little light humour
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.
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.
The world looks so different after learning science. For example, trees are made of air, primarily. When they are burned, they go back to air, and in their flaming heat is released the flaming heat of the Sun which was bound in to convert air into tree.
- Dave the bass
- Amstrad Tower of Power
- Posts: 12276
- Joined: Tue May 22, 2007 4:36 pm
- Location: NW Kent, Darn Sarf innit.
#2679 Re: A little light humour
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!
That'd be handy.
And whahey!
"The fat bourgeois and his doppelganger"
- Mike H
- Amstrad Tower of Power
- Posts: 20189
- Joined: Sat Oct 04, 2008 5:38 pm
- Location: The Fens
- Contact:
#2680 Re: A little light humour
Fascinating all!
I was going to say, 'What have I started now ...'
Anyhoo, the next one I fancied posting was this .....
-
I was going to say, 'What have I started now ...'
Anyhoo, the next one I fancied posting was this .....
-
"No matter how fast light travels it finds that the darkness has always got there first, and is waiting for it."
#2681 Re: A little light humour
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
#2682 Re: A little light humour
Its almost as if there were things in the past that happened before 1970.
Whenever an honest man discovers that he's mistaken, he will either cease to be mistaken or he will cease to be honest.
#2683 Re: A little light humour
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.
Just an example how small, safe seeming changes can come around to bite you.
Whenever an honest man discovers that he's mistaken, he will either cease to be mistaken or he will cease to be honest.
- jack
- Thermionic Monk Status
- Posts: 5504
- Joined: Wed Dec 29, 2010 8:58 pm
- Location: ɐılɐɹʇsnɐ oʇ ƃuıʌoɯ ƃuıɹǝpısuoɔ
- Contact:
#2684 Re: A little light humour
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.
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.
Vivitur ingenio, caetera mortis erunt
#2685 Re: A little light humour
An eagle may soar, but weasels dont get sucked into jet engines