Computer Science Canada The 2038 Syndrome: Second Coming of Y2K |
| Author: | randint [ Fri Apr 19, 2013 5:33 pm ] | ||
| Post subject: | The 2038 Syndrome: Second Coming of Y2K | ||
So, I read about the 2038 syndrome, which manifests itself as the inability of a computer system to tell time after January 19, 2038, at 03:14:07 AM, UTC. Here is a diagnostic test:
I do not understand why it compiles with an error (i.e. it runs but then pops up with an error)...could my computer have been tested positive for this syndrome? |
|||
| Author: | Nathan4102 [ Fri Apr 19, 2013 5:45 pm ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
The 2038 "crisis" isn't so much of a syndrome, and you don't really need to test to see if your computer will be affected. Any 32 bit computer won't be able to tell the date after January 19, 2038 because that date is based on the number of seconds since the 1'st of January, 1970. On January 19 2038, the number of seconds will reach the 32 bit integer limit, and wrap back to 0. I wouldn't worry about it, by 2038, 32 bit computers will be non-existent, or at least rarely used, since 64+ bit will be used in most homes. Also, computers that use different methods for telling time wouldn't be affected. The "Seconds since Jan. 1, 1970" thing though is used in the majority of home computers. |
|
| Author: | mirhagk [ Fri Apr 19, 2013 7:33 pm ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
Except it's already manifesting itself. For instance I know a server set a default time-out to a ridiculous value in the future (it was like 1 million), which caused problems back in 2006, since the timeout value wrapped around and everything was passed the timeout date. And also all consumer computers should be 64 bit then (by the way notice how long it's already taken, I wouldn't be so quick to automatically assume). I know microcontrollers and embedded systems might not be 64 bit by then, especially in systems that are old (imagine a car 20 years old in 2038, and it was made just 5 years in the future). It could definitely be a problem for certain systems. |
|
| Author: | randint [ Fri Apr 19, 2013 8:16 pm ] |
| Post subject: | Re: The 2038 Syndrome: Second Coming of Y2K |
In other words, you claim that all 64-bit computers will not be affected? If so, I do not need to worry, as I will buy a 64-bit computer in 2 months. Also, I think that the corporate world is going to stick to 32-bit for some time. You see, I am going to use as many 64-bit applications as possible. |
|
| Author: | btiffin [ Fri Apr 19, 2013 8:24 pm ] |
| Post subject: | Re: The 2038 Syndrome: Second Coming of Y2K |
y2k was a cake walk compared to the embedded nature of the epoch problem. Human nature to shorten dates to two digits was a visible issue. The zero rollover will go unseen, the consequences, not so much. The problem won't go away by attrition, it'll be a concerted effort, left till the last minute. Everyone here has 25 years to build up a little expertise in epoch mitigation. Believe me, 2036 will be a lucrative year for C programmers, then by 2038 the monied people of the earth will be all ticked off at nerds again, and a 2000 dotcom style bust will follow, and 2040 will be a crap year for all programming. Or, politicians will do away with that pesky fiduciary responsibility thing, and the steel mills, hydro grids and elevators will be on their own, to fail safe or not. Cheers (And by the way, look at some cheques, 2 digit years already, we learn nothing) |
|
| Author: | md [ Fri Apr 19, 2013 8:47 pm ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
Time problems are more annoying then you'd think: consider the case of a 25 year loan being made next year and you'll see why. |
|
| Author: | Nathan4102 [ Fri Apr 19, 2013 8:50 pm ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
As consumers though, or customers to the bank, would we really have anything to worry about? Obviously the bank's would remember the consequences of Y2K, and switch to 64 bit systems or some other integer-overflow prevention system before the date. And if they don't, they'd have to correct everything or lose customers. |
|
| Author: | randint [ Fri Apr 19, 2013 9:19 pm ] |
| Post subject: | Re: The 2038 Syndrome: Second Coming of Y2K |
The problem here [for 2038] is that it is far more difficult to raise awareness about 2038 than Y2K, due to the lack of mathematical knowledge among the public. I think that the concept is very simple--it traces back to the Pascal's triangle, and the sum of any given row of the Pascal's triangle. The idea is, let r denote the row number of a positive integer, and S(r) denote the sum of this row of the Pascal's triangle, then S(r)=2^r, where "^" is "to the power of". But a division by 2 is necessary, as integers are allowed to be either positive or negative. a -1 is necessary as 0 takes a bit. So, from a mathematical perspective, there are 2 functions that would denote the maximum value and minimum value of an integer, respectively, given the number of bits: max_int (bit) = 2^(bit - 1) - 1 min_int (bit) = -2^(bit - 1) Where the variable "bit" represents a positive integer, and the above ranges are inclusive, [e.g. if (bit = 32), then an integer can go from -2147483648 to 2147483647. |
|
| Author: | Sly14Cat [ Sat Apr 20, 2013 6:46 am ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
Therefore..... |
|
| Author: | mirhagk [ Sat Apr 20, 2013 7:31 am ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
md points out, the problem will manifest itself much sooner than a lot of people realize. A 25 year loan taken out next year would break the 32 bit barrier. Hopefully the bank has upgraded, but the last time I was at any non-compsci business, they were all still using XP at the latest. |
|
| Author: | randint [ Sat Apr 20, 2013 9:36 am ] |
| Post subject: | Re: The 2038 Syndrome: Second Coming of Y2K |
mirhagk, it is not about Windows XP, Vista, 7 or 8. The problem is whether or not the system, and all programs running under it, are 64 bit. The corporate enironment is very resistant to change. One of the technicians I talked to (who works for the York Region District School Board) claims that "all board computers will be upgraded from Windows XP 32 bit to Windows 7 32 bit in the Fall of 2013". You see, the problem will still exist if 32 bit is used. For me, my home laptop (which was purchased 2 years ago) is 64 bit Windows 7. I will buy a laptop soon, and it will be 64 bit as well, seeing that this is now the new standard for computers. |
|
| Author: | mirhagk [ Sat Apr 20, 2013 11:52 am ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
My point is that systems don't change very often. XP is what, 12 years old now, and the majority of businesses/schools are still using it. Plus they are using the 32 bit version. Also XP is the earliest windows system that has a 64 bit option, and that was added after the fact. Last time I was in the bank (a few weeks ago), the agent was using what looked like windows 98. I severely hope it was just a classic UI, but who knows. I know my mom's 2nd job required her to do medical billing, and she was using pre-95 up until last year. That's 25 years, which means 32 bit machines today might still be use in 2038. As for the school board, it sounds like they'll upgrade next when windows 10 comes out (to windows 9). Fortunately .NET software does not suffer from the same problem, as it abstracts time into an object, stores ticks as a 64 bit variable (which could easily be changed without requiring recompiling) and things like milliseconds are floating point values, and storing time is done as a string. I think switching consumers to 64 bit should be hopefully done pretty soon, I wouldn't be surprised if windows 9 dropped 32 bit support altogether. Soon 64-bit applications might actually start being released (currently most software is still just 32 bit, which makes me mad for things like games which could use the extra 4 GB I have on my machine) |
|
| Author: | randint [ Sat Apr 20, 2013 7:28 pm ] |
| Post subject: | Re: The 2038 Syndrome: Second Coming of Y2K |
There are still major problems that will hinder us from curing this fatal syndrome, namely, the lack of 64 bit applications. Again, as simple as it sounds, a 64-bit version of VLC Media Player is only in the development (beta testing) stage. By the way, Visual Studio 2012 does not have any 64 bit version whatsoever. These things need to be fixed, as 32 bit will become outdated and unreliable. I do not understand this: why was it so easy for the corporations to switch from 16-bit to 32-bit in the 1990s, when it is almost impossible to switch from 32-bit to 64-bit in the 2010s? This does not make sense...maybe because the economy is in **** right now. |
|
| Author: | btiffin [ Sun Apr 21, 2013 12:39 am ] |
| Post subject: | Re: The 2038 Syndrome: Second Coming of Y2K |
Don't worry about banks. Banks will pony any and all monies needed to avoid fiduciary responsibility risk. Worry about small embedded chips controlling pressure valves in the manure pile plant. The manure guy doesn't have other people's money to throw at virtual problems, so, these are the places that the epoch problem may be most felt. Y2K was pretty much a big business issue. Manure pile pressure valves wouldn't have cared two noogies about human formatted date strings, or if they were wrong, as internal timers don't usually speak in human formts. 2 digit dates are a human, and a visible problem. Epoch rollover is non-obvious, even for people that are "watching". Big business will get past the epoch, with a little moaning afterwards (moaning which will lead to removal of software development fun money, just like after y2k bills came in). Midsized enterprise may not have those resources, let alone an inventory of what chips might still be running 4 bytes of seconds come 2038, or which of these chips will fail dangerous when time jumps backwards almost 70 years from one second to the next. But, humans are led by people that want to survive too (while building up the stacks of cash), so stuff will happen. I expect a panic, well paid C grunts for a while, a fizzle and very few explosions, if any. I'd like to see less panic, but that'd be asking humans to look further ahead than next quarter. Cheers |
|
| Author: | mirhagk [ Sun Apr 21, 2013 7:38 am ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
It won't be 70 years though, it'll be 140, because it'll go negative 70 years. |
|
| Author: | randint [ Sun Apr 21, 2013 12:50 pm ] |
| Post subject: | Re: The 2038 Syndrome: Second Coming of Y2K |
Wait, are you saying that embedded chips are still using 32-bit epoch settings due to the high cost of using 64-bit? But, could any of you explain what type of embedded chips you are talking about? Because I suppose if too many devices (such as refrigerators, microwave ovens and regular ovens) will fail due to the epoch rollover, then these manufacturers need to think seriously about how they are going to make their next generation products 2038-compliant. Remember, no matter how high the cost is, if some fatal technological glitch prevents a device from running after a certain time, then it has to be fixed, or else the manufacturer goes out of business and no one on Earth will be able to use these devices after January 19, 2038. |
|
| Author: | Insectoid [ Sun Apr 21, 2013 1:08 pm ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
I don't think most refrigerator manufacturers expect their products to remain in use by 2038. By 2030, 64-bit chips will probably be pretty cheap. The company would probably love it if everyone had to replace their appliances within 8 years of purchase, even if it's a one-time deal. Besides, what's the worst that will happen? Oh, boo hoo, your microwave can't tell time anymore. It still microwaves things though, right? Important things like your car's computer will have to be replaced, and expensive things like that will probably have upgrade packages available. |
|
| Author: | copthesaint [ Sun Apr 21, 2013 1:13 pm ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
People already have learned about these things. In 2000 they had to deal with upgrading electronics, however they started years in advance to 2000. My electrical teacher from high school started replacing PLCs in the mines 4 years before 2000. People aren't stupid and they will start replacing things many years in advance to 2038. OR any Y2K threat crap. |
|
| Author: | randint [ Sun Apr 21, 2013 5:11 pm ] |
| Post subject: | Re: The 2038 Syndrome: Second Coming of Y2K |
Hmm, yeah, a car purchased in 2013 is probably not going to be usable in 2038 (I project that they have a maximum lifespan of 15 years, not 25). So I hope by 2028, this problem gets fixed. But still, WHY ARE 64-BIT CHIPS EXPENSIVE ENOUGH FOR THEM TO NOT BE FEASIBLE TO BE USED IN EMBEDDED SYSTEMS? |
|
| Author: | Insectoid [ Sun Apr 21, 2013 7:24 pm ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
I don't think they're that expensive, however if your job is to cut costs, and the 32-bit chip costs $3 less, you're gonna take it. |
|
| Author: | randint [ Sun Apr 21, 2013 9:27 pm ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
But what if doing so will prevent a piece of hardware from operating properly (if at all) after 2038? |
|
| Author: | Insectoid [ Sun Apr 21, 2013 9:50 pm ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
If they designed their products to survive beyond 2038, they would go out of business. |
|
| Author: | randint [ Sun Apr 21, 2013 9:55 pm ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
Wait...ARE YOU SURE that 64 bit computers are in no way affected? Because there is this 25 year mortgage problem that involves dates post-2038! |
|
| Author: | Insectoid [ Sun Apr 21, 2013 10:59 pm ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
32-bit programs running on 64-bit computers will still show errors, however I imagine most important software will be updated to 64 bits by then. Time is stored in a register (or a memory address, but that's not important). In a 32 bit computer, that register is 32 bits long, and that register will overflow to around negative 2 billion, which you can imagine will do some pretty weird things. In a 64 bit computer however, the register is (you guessed it!) 64 bits long, which can store about 9 quintillion, easily enough to store dates millions of years in the future, effectively ensuring the 2038 problem will never happen again. |
|
| Author: | randint [ Mon Apr 22, 2013 6:05 pm ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
Or, by the time it happens (to 64 bit hardware), 128 bit will be outdated. |
|
| Author: | mirhagk [ Mon Apr 22, 2013 7:48 pm ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
By that time binary will be outdated. |
|
| Author: | randint [ Mon Apr 22, 2013 7:58 pm ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
[I am a Java programmer]: so, tell me, is there any way to compile x64 code? I mean, I feel that I must write x64 code, and not go back to x86, ever. I know that Java is 2038 compliant, as it sets up 64-bit integer time representations (where the number is the number of miliseconds since what looks like January 1, 1970 00:00:00 UTC). |
|
| Author: | Insectoid [ Mon Apr 22, 2013 8:28 pm ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
Java compiles to a bytecode that runs in a virtual machine, which allows it to be platform-independent. I'm not sure about the specifics, but 64-bit systems will run the 64-bit VM, and 32-bit systems will run the 32-bit VM. I don't know how or if this affects program execution, though. |
|
| Author: | DemonWasp [ Mon Apr 22, 2013 9:23 pm ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
Largely, the JVM makes the execution environment the same between x86 and x64 systems (after all, that's the reason it exists--to make all platforms look the same). There are some differences: 32-bit JVMs cannot address more than 4GB of RAM (even on a 64-bit OS), while 64-bit JVMs require more space for each pointer (8 bytes instead of 4 bytes) and will therefore consume more RAM, though there's a switch to tell the JVM to use 4-byte pointers in 64-bit mode, whenever possible. There are no special switches to use a special version of Java that's 64-bit, and there's no need to recompile any programs. Install a 64-bit JVM and suddenly all your Java programs are 64-bit programs. |
|
| Author: | QuantumPhysics [ Tue Apr 23, 2013 7:40 am ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
Strange, my compiler allows me to go beyond 2038 and im using 32 bit. EDIT: Maybe mine is type-zero ... lol |
|
| Author: | Insectoid [ Tue Apr 23, 2013 2:01 pm ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
Your compiler doesn't care if you go over 2038. Your program might not have any issues at all, depending on what you're using the dates for. Then again, depending on what you're using the dates for, your program may crash or give unexpected output. It's a logic error, not a syntax error. Compilers don't care about logic, only syntax. |
|
| Author: | randint [ Tue Apr 23, 2013 7:53 pm ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
Maybe you casted the time_t into a long and that is why it can go beyond 2038. |
|
| Author: | randint [ Fri Jul 19, 2013 12:43 pm ] | ||||
| Post subject: | Re: The 2038 Syndrome: Second Coming of Y2K | ||||
My computer does not suffer from 2038 syndrome! Yay! Terminal Output (Ubuntu 13.04, 64-bit) Perl script:
from this code
|
|||||
| Author: | btiffin [ Fri Jul 19, 2013 5:09 pm ] |
| Post subject: | Re: The 2038 Syndrome: Second Coming of Y2K |
randint; If only. 64 systems may (by and large) escape the epoch... (Gee, I know Tony dreads the puns, but I think that was an epoch ellipse) ...but not in the all. Not all software will successfully clock over the threshold. You need to know for certain that no code is using 32 bit seconds-since signed or unsigned integer time fields. That would mean verifying ALL sources that use time as integer, not just modern Perl, Python, Ruby, et al, libraries. Timers will likely prove the most hazardous, future value calculations might count as second most. Ancient embedded systems will probably be the most fun to remediate. No sources, hard to find EPROM readers, hard to find chip specs, etcetera. Anyone wanting to increase odds of scoring 'gold rush' work in 20 to 25 some years, might do well to read up on 8 bit processors like the Z-80 and 80C554 micro controllers. Cheers |
|
| Author: | btiffin [ Fri Jul 19, 2013 5:45 pm ] |
| Post subject: | Re: RE:The 2038 Syndrome: Second Coming of Y2K |
mirhagk @ Sun Apr 21, 2013 7:38 am wrote: It won't be 70 years though, it'll be 140, because it'll go negative 70 years.
Good point, but not quite right, and highlights how this can be a misleading problem with devils in the details. And thinking about it; 0 will be Jan 1970, -1 will be one second back from 1970, etc. zero though, resets to software assuming 1970. The magic 2 billion seconds mark (2147483648), signed ints wrap, and start counting down from -1, in most software systems which would assume 2's complement form, and that isn't the only representation that may be in use, in say an 8 bit elevator micro controller. Anyone here that thinks that elevators aren't installed with 30 year life expectancies, or planes don't have life expectancies in the 50 year range, or nuclear reactors, hydro dams, and on and on, is not seeing the world's infrastructure for what it is. Old, mostly hidden, and only fixed when it breaks, explodes or drops on someone's head. I'm 50 and I still have a few years left to make mistakes. I still get calls supporting software that is 30 years old with no sign of being replaced. (It's been virtualized off a Vax, but is still running - and yes it has epoch issues, even after a very expensive y2k remediation pass). Humans learn, then rinse and repeat. Banks are already using forms with 2 digit years. I arm waved for y2k through the 90's, and the thing that I learned to fear most was out of phase power generation. y2k had nothing to do with power plants; micro controllers don't count time in human string form. The epoch issue does influence power plants, and it'll need to be verified. Out of phase power grids are scary. So scary that I bet humans will panic before epoch ellipse, spend way too much money on mostly clown trained technicians and will fix and retrofit around the problem. I believe the will fix part. Humans want to live, and keep their hoards intact. So, advice from an old guy. Don't be a 40 year old clown come 2038; understand the problem, understand the binary representations, be able to talk about it with professionalism and correctness. If only to calm the nerves of your grandma when the hype hits in 2035. Umm, not to sound like I know anything technical about epoch. But I doubt it'll be my job to fix. I'll be 75, and bitching at you kids to fix all the flashing clocks, then yelling for everyone to get off my lan. Cheers |
|
| Author: | randint [ Fri Jul 19, 2013 8:27 pm ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
Actually, my computer was purchased 2 months ago from Dell. It looks like it is a 2013 model. No ridiculously old hardware can be found. Plus, I said Ubuntu 13.04, x64. Just wondering, does "sudo apt-get install <package>" ever install 32 bit software on a 64 bit computer? |
|
| Author: | nullptr [ Sun Jul 21, 2013 10:04 pm ] |
| Post subject: | Re: The 2038 Syndrome: Second Coming of Y2K |
I must be misunderstanding something. I thought that 32- or 64-bit systems referred to the size of the pointers used, not the size of integers themselves. For example, my computer is 64-bit but when I declare an int in C++, it still takes up only 32 bits. Doesn't that mean that the 2038 problem will be independent of whether systems are 32- or 64-bit? |
|
| Author: | randint [ Sun Jul 21, 2013 10:34 pm ] | ||
| Post subject: | Re: The 2038 Syndrome: Second Coming of Y2K | ||
I must say that I know very little, if nothing at all, about C/C++. I know Java (a C-like language). In Java, the keywords for primitive types are like this: boolean: only true or false, cannot be converted to, or convert from any other primitive type to this type byte: 8-bit signed integer ranging from -(2^7) to 2^7 - 1 char: 16-bit unsigned integer ranging from 0 to 2^16 - 1 short: 16-bit signed integer ranging from -(2^15) to 2^15-1 int: 32-bit signed integer ranging from -(2^31) to 2^31-1 float: 32-bit IEEE-754 signed floating point (decimal) number...I do not know the range long: 64-bit signed integer ranging from -(2^63) to 2^63 - 1 double: 64-bit IEEE-754 signed floating point (decimal) number...again, I do not know the range Anyhow, the idea of Java is that, when you do the following:
you are declaring a 32-bit signed integer (the only unsigned integer type in Java is char, there is no way to do "unsigned int" like you do in C++). I hope someone with the expertise can help confirm if anything I wrote here are correct. Also, Java works in a VM, whereas C++ runs natively on the system. |
|||
| Author: | DemonWasp [ Mon Jul 22, 2013 12:11 am ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
Unfortunately, the issue is a bit more complicated than has been discussed so far: Operating Systems The "bitness" of an operating system refers to how large of an address space it can address -- that is, how much space it can give pointers to. On 32-bit systems, the limit is of course 2^32 (disregarding Physical Address Extensions [PAE] which is a whole other can of worms). On 64-bit systems, it can vary (the upper limit is 2^64, but current versions of operating systems are often built to lower limits). The size a pointer uses is related, but not necessarily the same: 64-bit systems can use 32-bit pointers as well as 64-bit pointers. This is partially for backwards-compatibility, so that a 64-bit system can run 32-bit binaries. It can also allow 64-bit-aware code to use 32-bit pointers to save space (the Java Virtual Machine, JVM, can do that automatically). 64-bit Linux systems can install a mix of 32-bit and 64-bit software, and apt and aptitude (as well as probably all the other popular package managers) can handle resolving dependencies correctly so that they both have the libraries they need. Some distributions have made a concerted effort to make all their software available in 64-bit, but even so some software just isn't 64-bit yet. Using 32-bit software on a 64-bit system is seamless, so I'm not even sure which of the programs I use are 32-bit. But that's just pointers, not integer storage. Integers Languages vary in how they store integer data. Java has very well-defined types. Python has arbitrary-length integers, meaning they can store any value. C and C++ have less well-defined base types; for example, 'int' means "at least as many bits as there are in 'short' and at most as many as there are in 'long int'". You can imagine that since 'long' and 'short' are defined similarly, there are no set sizes for types in C or C++. Compilers are free to define what 'int' and 'short' and so forth actually mean. This is deliberate, as systems are free to define their memory model; most consumer systems have converged on 8 bits to a byte, 4 or 8 bytes to an int, etc (mostly, the Java model that randint posted). But some integrated systems (which are everywhere, but largely invisible) use variations, usually something like "2 bytes to an int" but sometimes some more exotic options. The whole matter becomes stupidly complicated when you add in character sets, which are what is used to interpret the bits inside a char into a character representation. The Epoch The only way to be sure that software is capable of handling dates past the 32-bit epoch is to either prove that mathematically (incredibly time-consuming, and difficult enough that you'd need a lot of expensive people to do so) or to set the system's time past the epoch and try every supported code path, verifying that dates are never mangled (which is also very difficult, as you'd have to recognize dates that have been mangled). It would be easy for a human tester to miss a mangled date while visually scanning, and there may not be a good automated solution. That means that the program source code (often millions of lines), database design (relatively small, but equally complex), and libraries (which may not even have the original source available!) need to be checked for compatibility. This applies to ALL operating programs that interact with dates, either directly or indirectly. Every database, every integrated system, every operating system, every library, every eggbeater calibration routine. Imagine looking over all the code you've ever written, looking for very subtle bugs. Now, imagine that someone else wrote it twenty years ago, didn't comment it, and has since retired. That is an enormous undertaking. Probably the more common solution, at least for non-essential software, will be "well, I hope it doesn't break" followed by "well, it broke, let's fix it". @randint: You're mostly correct, but Java is only C-like in appearance. Its design philosophy, specification, ecosystem, tooling, and applications are very different. The technical range of floating-point numbers isn't necessarily representative of the range over which they are most useful. Floating-point values are most densely packed around 0, and become increasingly sparse towards the positive and negative ends of the range. For very large numbers in Java, use BigInteger or BigDecimal, which are arbitrary-precision. |
|
| Author: | btiffin [ Mon Jul 22, 2013 3:07 pm ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
Great conversation people. These are the kinds of details anyone that wishes to speak to the epoch ellipse with any level of authority will need to know. Otherwise they'll just be another chicken little (and don't worry, as the date gets closer, you'll see a LOT of chicken littles running around in a panic, not even realizing that they still have their heads). Cheers |
|
| Author: | randint [ Mon Jul 22, 2013 8:00 pm ] |
| Post subject: | Re: The 2038 Syndrome: Second Coming of Y2K |
@DemonWasp: I am a little scared when you described C/C++ as very non-standard(ized) languages. Here is a thing: if I have a program written in C/C++, and it compiles perfectly well under one compiler, but when I compile it with a different compiler, it gives a syntax error (because of the "different" [and different is bad, because if a program needs to be multi-platform and work across all platforms without having to rewrite the code] way of implementing a language). Another scary thing is that you mentioned something about code written so long ago and the person retires (or even dies) -- or worse, the source code is not available at all (I do not think there is a way to fix a program's bug if the source code is unavailable). So, do you think that Y2038 is a lot more complicated than Y2K? (I read somewhere that Y2K is not serious because it is just the way that time is displayed on the screen, as opposed to the way that time is represented in a computer, so that when the counter reaches 2^31 for time on January 19, 2038, and if the system [or any software installed on the system] can have some strange overflow-related error). Now, I will give my opinion: being a soon-to-be math student at the University of Waterloo, I believe that, a big part of this is how difficult it is to raise awareness. You see, Y2K is easy to understand: the year is represented using the last 2 digits (e.g. "1999" becomes "99" so that the rollover on January 1, 2000 would look like "00", seemingly the same as "1900" [also represented with "00", and therefore the root cause of date confusion]). Someone who fails to comprehend (or had forgotten about) high school level math (exponential functions, etc...) would have a very hard time understanding the difference between 32-bit and 64-bit (they think that 64-bit is twice as powerful as 32-bit when in fact (2^32)^2 = 2^64=18446744073709551616, as opposed to 2^32=4294967296. If you come to think about it, someone who does not have a reasonably good understanding of such math is unlikely to understand why January 19, 2038 is the doomsday of 32-bit computing. I really hope that more people are aware of the serious implications this have on anything that relies on computers (e.g. as above posters have mentioned, power plants, elevators are likely to stop working when the Epoch hits). |
|
| Author: | DemonWasp [ Mon Jul 22, 2013 11:30 pm ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
There are established standards for C and C++ (and several iterations of each standard), but they leave a lot of details unspecified, usually deliberately. You may have heard of "unspecified behaviour"? It's used as a catch-all in C and C++ standards, meaning "this is unsupported, so don't do it--your compiler is allowed to do whatever it wants if you do this!". It is frequently the case that compiler A and compiler B will disagree about whether any given program is valid, and perhaps more vexingly, what that program means. Even if you can get A and B to both compile your program, they may compile different behaviour. One topical example would be that int may mean 32 bits to compiler A, but only 16 bits to compiler B. If you're storing numbers above 2^15-1, then you're in for a rude surprise when your code doesn't work on compiler B, even though it compiles fine and worked on compiler A. This is, as you mention, a problem for cross-platform development. In real software, a few header files are usually used to smooth over these differences. Developers will usually target specific choices of compiler and platform ("gcc on linux, vc++ on windows", etc) and only really test those combinations. In the case of programs where the source is no longer available, it might be possible to patch the compiled binaries. However, that's both difficult and complex, and may well require more effort than just rewriting the program. I would argue that public awareness of the epoch issue isn't really necessary. Of course software developers and engineers should be aware of their issue, as should their managers. The people who are in charge of maintaining computers and software need to know. However, most people use computers for "the Facebook" or videogames or business applications, and for the most part don't need to know. Public scaremongering over this issue is pretty well worthless. While it'll be expensive for many companies to audit themselves for "epoch compliance" and generate some harrowing overtime experiences for a few software developers, the vast majority of people don't need to know. |
|
| Author: | btiffin [ Thu Jul 25, 2013 9:24 am ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
DemonWasp may be one of the rare voices of reason in the wilderness, so, you know: Don't listen to him. Run around, and panic Or, learn a little, and take advantage of the boom time that is coming. And prepare for the year or two of bust around 2040 as corporations readjust IT funding. And by advantage, I don't really mean 'take advantage', I mean be prepared to do some remediation work with enough know how to calm nerves and lead teams without wasting too too much of the company's monies. It'll be lucrative for a few, an opportunity to sell snake oil for a few others and for most, just another job. But, why not scare grandma in the meanwhile. She's old anyway and it serves her right for not learning how to program in POSIX. Cheers |
|
| Author: | randint [ Sun Jul 28, 2013 10:47 pm ] |
| Post subject: | Re: The 2038 Syndrome: Second Coming of Y2K |
Unfortunately, people like my father actually looks at things differently. He said "Yeah, so what? Even if 6 billion people dies in this world due to the lack of electricity, the world did not end, 1 billion still remain. " (I told him that there may be no electricity after January 19, 2038 due to this debilitating fatal incurable syndrome). (And yet, our household has 2 laptop computers, 1 iPad, 1 Windows Phone, 1 Blu-ray player, 1 Android phone and 1 "regular" cellphone). No, the older generation will not give a **** about losing electricity (and it did seem to me that my parents lived without electricity for much of their times when they were kids - may)be that is the reason?) I do not know, but they do not seem to be worried...even though I think cars cannot run without electricity (you need a battery to start the car). |
|
| Author: | mirhagk [ Mon Jul 29, 2013 9:31 am ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
Electricty won't be lost, big systems will all be fixed, I think the actual effects to happen would be that embedded devices in non-critical areas will not be fixed. You may notice that your dishwasher will stop functioning for instance, or your printer or maybe even tv (although those are getting more advanced, and a software upgrade will probably be very possible by then). An interesting solution would be allowing every device to receive firmware upgrades. I saw something a little while ago about some company considering doing this for laundry machines for example. If there was ever a problem they could simply push out a new firmware update without the user even knowing what was happening. It could prevent them from having to do a recall and even issues that would be too minor for a recall, but still major enough that users might be upset about it (and they'd lose future sales). We can force this to happen by writing some really awesome code for laundry machines, then just release it under GPLv3 (which forces them to allow the user to modify code, open source fridges FTW!) |
|
| Author: | randint [ Mon Jul 29, 2013 7:30 pm ] |
| Post subject: | Re: The 2038 Syndrome: Second Coming of Y2K |
As a technical question: how do you go about upgrading firmware of things like refrigerators, laundry machines, televisions and other non-Internet compatible devices? Your idea is amazing, but how do people go about installing such software? Thanks. |
|
| Author: | Nathan4102 [ Mon Jul 29, 2013 8:21 pm ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
First of all, take televisions off the list of non-Internet compatible devices. My TV is connected to the internet. I don't really know how fridges and laundry machines would connect to the internet. Perhaps a GUI of some sort where you can connect to your wifi? Or a small charge added to the price of a machine for a small cellular device inside the machine that checks for updates? Who knows! |
|
| Author: | randint [ Mon Jul 29, 2013 8:35 pm ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
OK, yeah, televisions can be WiFi compatible now. Anyhow, so I suppose it is pretty easy to add a 802.11g WiFi compatible device or whatever onto these things? Hmm...my DVD player needs a firmware upgrade... |
|
| Author: | mirhagk [ Tue Jul 30, 2013 7:46 am ] |
| Post subject: | RE:The 2038 Syndrome: Second Coming of Y2K |
Yep the company in question basically figured it'd add about $2 to the cost of the unit if they enabled it to be able to access cellular resources to check for updates. You could choose to connect to wifi instead, but that'd require configuring it for wifi. |
|