Nah, they will do what they always do. Change some system environmental variables to move the zero date on till after they would have retired.
Nobody wants to touch the original code, it was developed in the 1970s
1. Be civil
No trolling, bigotry or other insulting / annoying behaviour
2. No politics
This is non-politics community. For political memes please go to !politicalmemes@lemmy.world
3. No recent reposts
Check for reposts when posting a meme, you can only repost after 1 month
4. No bots
No bots without the express approval of the mods or the admins
5. No Spam/Ads
No advertisements or spam. This is an instance rule and the only way to live.
Nah, they will do what they always do. Change some system environmental variables to move the zero date on till after they would have retired.
Nobody wants to touch the original code, it was developed in the 1970s
In this thread: mostly people that don't know how timekeeping works on computers.
This is already something that we're solving for. At this point, it's like 90% or better, ready to go.
See: https://en.m.wikipedia.org/wiki/Year_2038_problem
Time keeping, commonly, is stored as a binary number that represents how many seconds have passed since midnight (UTC) on January 1st 1970. Since the year 10,000 isn't x seconds away from epoch (1970-01-01T00:00:00Z), where x is any factor of 2 (aka 2^x, where x is any integer), any discrepancies in the use of "year" as a 4 digit number vs a 5 digit number, are entirely a display issue (front end). The thing that does the actual processing, storing and evaluation of time, gives absolutely no fucks about what "year" it is, because the current datetime is a binary number representing the seconds since epoch.
Whether that is displayed to you correctly or not, doesn't matter in the slightest. The machine will function even if you see some weird shit, like the year being 99 100 because some lazy person decided to hard code it to show "99" as the first two digits, then take the current year, subtract 9900, and display whatever was left (so it would show the year 9999 as "99", and the year 10000 as year "100") so the date becomes 99 concatenated with the last two (now three) digits left over.
I get that it's a joke, but the joke isn't based on any technical understanding of how timekeeping works in technology.
The whole W2k thing was a bunch of fear mongering horse shit. For most systems, the year would have shown as "19-100", 1900, or simply "00" (or some variant thereof).
Edit: the image in the OP is also a depiction of me reading replies. I just can't even.
Y2K was definitely not only fear-mongering. Windows Systems did not use Unix timestamps, many embedded systems didn't either, COBOL didn't either. So your explanation isn't relevant to this problem specifically and these systems were absolutely affected by Y2K because they stored time differently. The reason we didn't have a catastrophic event was the preventative actions taken.
Nowadays you're right, there will be no Y10K problem mainly because storage is not an issue as it was in the 60s and 70s when the affected systems were designed. Back then every bit of storage was precious and therefore omitted when not necessary. Nowadays, there's no issue even for embedded systems to set aside 64 bit for timekeeping which moves the problem to 292277026596-12-04 15:30:08 UTC (with one second precision) and by then we just add another bit to double the length or are dead because the sun exploded.
... any discrepancies in the use of "year" as a 4 digit number vs a 5 digit number, are entirely a display issue (front end).
That's exactly how I read the meme. It would still require a change.
Whether that is displayed to you correctly or not, doesn't matter in the slightest. The machine will function even if you see some weird shit,
I'm not sure if this is some nihilistic stuff, or you really think this. Of course nothing actually matters. The program will still work even if the time is uint32 instead of uint64. The machine of course will still work as well. Shit, your life will go on. The earth continues to spin and this will for sure not cause the heat death of the universe. But aside from actual crashes and some functionality bugs, UI issues should be the ones you worry about the most. If your users are a bank and they need to date the contracts, and you only offer 3 digits for the year? I think you'll agree with me that if users don't like using your program, it's a useless program.
My brother in Christ, there's more to time than just storing it. Every datetime library I've ever used only documents formatting/parsing support up to four year digits. If they suddenly also supported five digits, I guarantee it will lead to bugs in handling existing dates, as not all date formats could still be parsed unambiguously.
It won't help you if time is stored perfectly, while none of your applications support it.
Regarding Y2K, it wasn't horse shit - thousands upon thousands of developer hours were invested to prevent these issues before they occurred. Had they not done so, a bunch of systems would have broken, because parsing time isn't just about displaying 19 or 20.
I would hope that these kinds of parsers are not used in critical applications that could actually lead to catastrophic events, that's definitely different to Y2K. There would be bugs, yes, but quite fixable ones.
Regarding Y2K, it wasn't horse shit - thousands upon thousands of developer hours were invested to prevent these issues before they occurred. Had they not done so, a bunch of systems would have broken, because parsing time isn't just about displaying 19 or 20.
"There's no glory in prevention". I guess it's hard to grasp nowadays, that mankind at some point actually tried to stop catastrophies from happening and succeeded
Even if such parsers aren't used directly in critical systems, they'll surely be used in the supply chains of critical systems. Your train won't randomly derail, but disruptions in the supply chain can cause repair parts not to be delivered, that kind of thing.
And you can be certain such parsers are used in almost every application dealing with datetimes that hasn't been specifically audited or secured. 99% of software is held together with duct tape.
True. But I wouldn't see this as extremely more critical than the hundreds of other issues we encounter daily in software. Tbh, I'd be glad if some of the software I have to use daily had more duct tape on it...
Actual programmers wondering why this joke doesn't mention 65535...
More of a front end issue actually, almost all time is just stored as the number of seconds since 00:00:00 Jan 1 1970.
And it's represented as a 64 bits value, which is over 500 billions years.
64 bits value
.... About that... https://en.wikipedia.org/wiki/Year_2038_problem
That's the 32 bit timestamp
We've still got time to fix it, and the next release of Debian will likely have a time-64 complete userland. I don't know the status of other "bedrock" distributions, but I expect that for all Linux (and BSD) systems that don't have to support a proprietary time-32 program, everything will be time-64 with nearly a decade to spare.
oh just start at 0000 again, signate that as 10,000. Files didn't start until like 1979 anyways, and there can't be many left, and even if it is a problem, now you have 2000 years to not worry about it.
Good news! We'll be exctinct long before this happens. One less thing to worry about!
Seems hyperbolic to assume we will be extinct by 9999.
Sure we’re heading for a climate crisis, but I don’t think all humans will be dead; Just the poorest.
That has forever been the fallacy.
The poor won't die in the apocalypse leaving only the rich behind. The poor will die, and the rich will be faced with the harsh reality that they needed an army of poor working under them to sustain themselves, leading them to all die within the generation.
That's true until it isn't. Automation is on its way. Marching ever onward.
The factory I work in built a new building this year that employs 1/4 of the workers as the next newest one and does 2.5x the output.
You still need loaders, drivers, retailers to get anything to the customer. A lot of rich ski and holiday towns can't staff the stores and Cafe's, because the employees can't afford to pay rent in the same towns, so they face a similar issue...
Y10K.
The trick is to unplug our computer a few seconds before midnight on December 31st, 9999 and then plug in the wire again
Yo I dunno what you made me do but now I got the y10k virus, help
We’re being short-sighted
Tell that to the billionaires speed-running terraforming this planet into a barren wasteland.
Programmers in 292,271,023,045 after uint64_t isn't enough for the unix timestamp anymore:
Programmers dealing with the timezones of asymmetric period binary and trinary star systems once we go interstellar 💀
Please no.
Don't worry, we'll be extinct soon, hopefully. Maybe even before int32_t runs out. Unfortunately not soon enough to stop the humans impact on earth before the worst damage is done.
I'll let you in on a secret.
Humanity and the animals that we like will get through just fine.
Humans in general and the vast majority of biodiversity will be fucked if it ever happens.
I firmly believe it won't. Too many good people in the world doing far more than the shitty ones.
Except the shitty ones have more money and political power.
well there have been mass extinctions before, the most notable maybe oxygenation catastrophe , mainly caused by photosynthetic life.
And it represented a major breakthrough for life on Earth, so i doubt that this one is an irreparable crisis.
I don't think 10000 year is a problem. There is a real "year 2038 problem" that affects system storing unix time in signed int32, but it's mostly solved already. The next problem will be in year 33000 or something like that.
I've been curious about that myself. On one hand, it still seems far away. On the other hand, it's a bit over 13 years away now and I have gear actively in use that's older than that today.
There are so many problems there is an entire Wikipedia page dedicated to them.
Well, I looked at a Year 10000 problem less than 2 hours ago. We're parsing logs to extract the timestamp and for that, we're using a regex which starts with:
\d{4}-\d{2}-\d{2}
So, we assume there to be 4 digits for the year, always. Can't use it, if you live in the year 10000 and beyond, nor in the year 999 and before.
Just start over at year 0000 AT (after ten thousand)
It’s a UX problem rather than a date format problem at that point. Many form fields require exactly 4 digits.
In 9999, this meme will be problematic because it assumes the entire galaxy conforms to an Earth-based calendar system.
Well the USA is on Earth so obviously the earth calendar is the default.
Still set by London 😂
There might be a new calendar year system by then. Probably some galactic dictator who says that the beginning of their rule is now Year Zero.
Year Zero of the Glorious Zorg Empire!
Awww shit, time to rewatch my favourite Jike Mudge movie starring Lon Rivingston; Space Office (9999).
Haha, I can't believe this guy has the job of manually changing all the dates on the company's database, this place sucks. I bet the past was way better.
"Were being short-sighted"
Lol Picard maneuver. Pretty sure your opinion wasn't asked for.
The Butlerian jihad will have happened by then.