re: the 2020 bug because of bad y2k fixes: 10$ says that we'll see the same problem in 2040 because some programmers quick-fixed the program by just changing the cut-off date
-
-
the real reason it'll be a problem is because y2k was really just a "human problem". computers don't care about Gregorian dates like "2020", they don't tell time that way. They just have to convert to/from those kinds of dates sometimes because humans like 'em
Prikaži ovu nit -
but the unix epoch is how computers tell time. it won't just be a y2k issue where the computer is telling humans the wrong time, it'll be computers not being able to tell time for themselves, and that will be a million or billion times worse
Prikaži ovu nit -
like you'll boot your computer and before it can do anything it'll freak out that your hard drive hasn't been checked for errors in 68 years
Prikaži ovu nit -
and god forbid the computer is running at the switchover time. basically every program running will think time went backwards
Prikaži ovu nit -
so hopefully we will get really serious about patching this shit before it happens. hopefully.
Prikaži ovu nit -
heck it's incredibly common to do things like calculate dates by taking the current time (against the unix epoch) and adding some number of seconds.
Prikaži ovu nit -
like, nearly every site that calculates when your login expires does it by taking the unix timestamp, adding some number or seconds. like: cookie.expire=time()+365*24*60*60 # expire in 1 year
Prikaži ovu nit -
and in 2037 that calculation is going to start saying "OH YEAH SET THE EXPIRATION DATE TO 1970 THAT'S NORMAL AND FINE"
Prikaži ovu nit -
so now you can't login to a website. because the cookie date is wrong.
Prikaži ovu nit -
and this is going to happen separately to basically EVERY SINGLE FUCKING PROGRAM and they're all going to have to be patched or replaced differently and it's going to be a nightmare
Prikaži ovu nit -
and this is such a big problem compared to y2k because of how ingrained it is. y2k was caused by a common design pattern being wrong. people just tended to design sites with 2-digit years, right? and that eventually came back to bite us
Prikaži ovu nit -
but y2038 is INGRAINED INTO THE C PROGRAMMING LANGUAGE ITSELF the standard library function time() returns seconds since 1970!
Prikaži ovu nit -
and given that basically every other programming language in common use is based on or derived from or at least maintains compatibility with C... they all do it too.
Prikaži ovu nit -
and relatedly it's also central to Unix (that's why it's the unix epoch) which is the basis (or at least a major influence on) every OS since then.
Prikaži ovu nit -
so it's almost a fundamental flaw in the design of modern computing and so many things are going to break because of this.
Prikaži ovu nit -
In any case, since I didn't really explain why it's a problem, just assumed it: The C programming language and unix store time as the number of seconds since 1970, and they do it using a 32bit signed integer.
Prikaži ovu nit -
and the largest value you can store in a 32bit signed integer is 2**31-1, or 2,147,483,647. And it turns out that 2,147,483,647 seconds from 1970 is January 19th, 2038.
Prikaži ovu nit -
So after that moment, it'll wrap around (probably: it's technically undefined behavior) to the most negative number, and the computer will go "OH YEAH IT'S NOW DECEMBER 13, 1901, RIGHT?"
Prikaži ovu nit -
but the fact that it's 1901 isn't the problem, really. computers have no problem 1901! that's a human date, computers don't care.
Prikaži ovu nit -
yeah they'll tell some humans that their bank loan is now issued for the year 1901 but who cares no the problem is that when computers try to compute the day after January 19th 2038, they get December 13th 1901, which is earlier.
Prikaži ovu nit -
So a program tries to run a task for an hour, and ends up stopping it instantly, because now() + 1 hour is IN THE PAST
Prikaži ovu nit -
because the common pattern for doing things like that is to do something like this: end_time = time() + 60*60 while time() < end_time: do_the_thing()
Prikaži ovu nit -
but when you're near 19th of January, 2038, the overflow happens in the addition, and end_time ends up being way before time(), so it never runs the thing at all.
Prikaži ovu nit -
and it's easy to think about this as a problem of "oh no one will be running old code by then" but you can seriously write code that does this today and it's the easiest way to do it and that's probably not going to change anytime soon.
Prikaži ovu nit -
so in 2038 we'll not have this problem with code from 1980 or 2000 or 2020, we'll have this problem with code from 2030 as well
Prikaži ovu nit -
so this is going to be a problem on the scale of "re-test and fix every program ever written"
Prikaži ovu nit -
like, around when the y2k fixing effort really spun up, there were a lot of retired cobol & fortran programmers being called up to help fix it
Prikaži ovu nit -
in 2036 you're gonna have everyone who has "programming" on their resume called up because we're going to need to fix every program running anywhere, basically.
Prikaži ovu nit -
Although to move away from the apocalyptic stuff, the one thing that'll hopefully help us is interpreted dynamically typed languages like Javascript that run on standard runtimes.
Prikaži ovu nit -
because you can fix the runtime and hopefully it won't break any programs to suddenly start getting 64-bit integers instead of 32-bit ones. In theory you could modify javascript to start doing the fix to this today, and 99% of JS programs won't notice.
Prikaži ovu nit - Još 3 druga odgovora
Novi razgovor -
Čini se da učitavanje traje već neko vrijeme.
Twitter je možda preopterećen ili ima kratkotrajnih poteškoća u radu. Pokušajte ponovno ili potražite dodatne informacije u odjeljku Status Twittera.