this post was submitted on 06 Nov 2023
970 points (98.3% liked)
Comic Strips
12478 readers
4966 users here now
Comic Strips is a community for those who love comic stories.
The rules are simple:
- The post can be a single image, an image gallery, or a link to a specific comic hosted on another site (the author's website, for instance).
- The comic must be a complete story.
- If it is an external link, it must be to a specific story, not to the root of the site.
- You may post comics from others or your own.
- If you are posting a comic of your own, a maximum of one per week is allowed (I know, your comics are great, but this rule helps avoid spam).
- The comic can be in any language, but if it's not in English, OP must include an English translation in the post's 'body' field (note: you don't need to select a specific language when posting a comic).
- Politeness.
- Adult content is not allowed. This community aims to be fun for people of all ages.
Web of links
- !linuxmemes@lemmy.world: "I use Arch btw"
- !memes@lemmy.world: memes (you don't say!)
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
https://en.m.wikipedia.org/wiki/Year_2000_problem
Generic summary: Two digit clocks hitting 00 thinking its 1900 not 2000.
I wonder why they didn't think about making computers and clocks count past 100 when creating them? Did they not expect to ever get to the year 2000?
Early computers had very limited resources, RAM, storage, etc. (first computer I worked with only had 4k of RAM for example) It often made sense to only use the last 2 digits of the year as an optimization in many common tasks that computers were used for, as both the 1800s and the 2000s were far enough away that most basic date calculations worked fine. Also, the industry was changing rapidly, and few people expected their software to be used for more than a few years - certainly not for decades, so focus was usually on solving the immediate tasks as efficiently as possible, without much consideration for the distant future.
However, it turned out that a lot of the code written in this period (70s and 80s) became "legacy code" that companies started relying on for far longer than was expected, to the point that old retired COBOL programmers were being hired for big $$ in late 90s to come and fix Y2K issues in code written decades ago. Many large systems had some critical ancient mainframe code somewhere along the dependency chains. On top of that, even stuff that was meant to handle Y2K was not always tested well, and all kinds of unexpected dependencies crept up where a small bug here, or some forgotten non-compliant library there could wreak havoc once date rolled over into the 2000s.
A lot of the Y2K work was testing all the systems and finding all the places such bugs were hiding.
that's interesting, thank you!