Yeah I would imagine poor/lazy planning or they either thought their tools would be replaced by then and/or that computers were just a fad so there’s no way they’d be used in the year 2000.
But generally, back in the day data storage, memory and processing power were expensive. Multiple factors more expensive than they are now. Storing a year with two digits instead of four was a saving worth making. Over time, some people just kept doing what they had been doing. Some people just learned from mentors to do it that way, and kept doing it.
It was somewhat expected that systems would improve and over time that saving wouldn’t be needed. Which was true. By the year 2000 “modern” systems didn’t need to make that saving. But there was a lot of old code and systems that were still running just fine, that hadn’t been updated to modern code/hardware. it became a bit of a rush job at the end to make the same upgrade.
There is a similar issue coming up in the year 2038. A lot of computing platforms store dates as the number of seconds since the beginning of 1970-01-01 UTC. As I type this comment there have been 1,710,757,161 seconds since that date. It’s a simple way to store time/date in a way that can be converted back to a human readable format quite easily. I’ve written a lot of code which does exactly this. I’ve also written lot of code and data storage systems that store this number as a 32bit integer. Without drilling down into what that means, the limit of that data storage type will be a count of 4,294,967,296. That means at 2038-01-19 03:14:07 UTC, some of my old code will break, because it wont be able to properly store the dates.
I no longer work for that employer, I no longer maintain that code. Back when I wrote that code, a 32bit integer made sense. If I wrote new code now, I would use a different data type that would last longer. If my old code is still in use then someone is going to have to update it. Because of the way business, software and humans work. I don’t expect anyone will patch that code until sometime around the year 2037.
I often wonder what happened to the code I wrote in 2010 and used for production coordination & was working fine when I retired (2018). I figured the minute I left the hotshot kids would want to upgrade to their own styles. Not everyone liked it bc it wasn’t beautiful but no one could say it wasn’t functional, so it persisted. I was busy learning design and assemble CNC routers; but it worked and I didn’t have time to make a selection of backgrounds & banners. It’s just Excel, AutoCAD, & Access using VBA, which everyone has says they are going to deprecate VBA but, alas, people still want it. I remember Autodesk announcing the deprecation of VBA c. 2012 and I just looked and I guess they changed their mind bc there are modules for VBA available
The Mayans figured a calendar that only went to 2012 would be good enough. And they were right, their civilization didn’t exist anymore in 2012. Only relevance their calendar system had in 2012 was that some people felt like it was a prophecy about the end of the world. Nope, just was an arbitrary date the Mayans rightly assumed would be far enough away it wouldn’t matter.
While I suppose you could make a date format that was infinitely expandable, it would take more processing power and is really unnecessary.
Anyway got until 2038 until we’ll have to deal with a popular date format running out of bits. We’ll probably be in some kind of mad max post apocalyptic world before then so it won’t matter.
That’s a misconception. The Maya (not Mayan, that’s the language) long count for December 20, 2012 was 12.19.19.17.19. December 21, 2012 was 13.0.0.0.0. Today is 13.0.11.7.4. It continues the same way indefinitely, it’s just the number of days since some arbitrary date (August 11, 3114 BCE if you’re curious) in base 20, with the second to last digit in base 18, which seems odd at first but it rather cleverly makes it so the third digit can stand in as a rough approximation of years, and the second is approximately a generation. Now October 13, 4772 could be seen as an endpoint but there’s nothing that says it can’t be extended with one more digit to 1.0.0.0.0.0, and then you’re good for another 150,000 years or so.
Now there was a creation myth that said 0.0.0.0.0 was the previous world’s 13.0.0.0.0, but there was no recorded belief that this was any sort of recurring cycle, in fact plenty of Maya texts predicted astronomical events millennia past 2012. The idea that it was recurring was probably borrowed from the similar Greek construct of ekpyrosis, which doesn’t specify any sort of time frame.
That’s fuckin wild and seems like a massive oversight.
Did they just not expect us all to live that long or did they just not think of it at all?
Yeah I would imagine poor/lazy planning or they either thought their tools would be replaced by then and/or that computers were just a fad so there’s no way they’d be used in the year 2000.
Depends on the “they”…
But generally, back in the day data storage, memory and processing power were expensive. Multiple factors more expensive than they are now. Storing a year with two digits instead of four was a saving worth making. Over time, some people just kept doing what they had been doing. Some people just learned from mentors to do it that way, and kept doing it.
It was somewhat expected that systems would improve and over time that saving wouldn’t be needed. Which was true. By the year 2000 “modern” systems didn’t need to make that saving. But there was a lot of old code and systems that were still running just fine, that hadn’t been updated to modern code/hardware. it became a bit of a rush job at the end to make the same upgrade.
There is a similar issue coming up in the year 2038. A lot of computing platforms store dates as the number of seconds since the beginning of 1970-01-01 UTC. As I type this comment there have been 1,710,757,161 seconds since that date. It’s a simple way to store time/date in a way that can be converted back to a human readable format quite easily. I’ve written a lot of code which does exactly this. I’ve also written lot of code and data storage systems that store this number as a 32bit integer. Without drilling down into what that means, the limit of that data storage type will be a count of 4,294,967,296. That means at 2038-01-19 03:14:07 UTC, some of my old code will break, because it wont be able to properly store the dates.
I no longer work for that employer, I no longer maintain that code. Back when I wrote that code, a 32bit integer made sense. If I wrote new code now, I would use a different data type that would last longer. If my old code is still in use then someone is going to have to update it. Because of the way business, software and humans work. I don’t expect anyone will patch that code until sometime around the year 2037.
A little nitpick: the count at that time will be 2,147,483,647. time_t is usually a signed integer.
I often wonder what happened to the code I wrote in 2010 and used for production coordination & was working fine when I retired (2018). I figured the minute I left the hotshot kids would want to upgrade to their own styles. Not everyone liked it bc it wasn’t beautiful but no one could say it wasn’t functional, so it persisted. I was busy learning design and assemble CNC routers; but it worked and I didn’t have time to make a selection of backgrounds & banners. It’s just Excel, AutoCAD, & Access using VBA, which everyone has says they are going to deprecate VBA but, alas, people still want it. I remember Autodesk announcing the deprecation of VBA c. 2012 and I just looked and I guess they changed their mind bc there are modules for VBA available
14 years ago at stackoverflow. What is the future of VBA? https://stackoverflow.com/questions/1112491/what-is-the-future-of-vba Download the Microsoft VBA Module for AutoCAD - Autodesk https://www.autodesk.com/support/technical/article/caas/tsarticles/ts/3kxk0RyvfWTfSfAIrcmsLQ.html Links to download for VBA modules for their products Feb 7, 2024 To install the Microsoft Visual Basic for Applications Module (VBA) for Autocad, do the following: Select the appropriate download from the list below. Close all programs. In Windows Explorer, double-click the downloaded self-extracting EXE file.
sometimes legacy methods last longer bc no one wants to be a hotshot.
you think that’s bad, just wait til 2038 when the UNIX time rolls over.
The Mayans figured a calendar that only went to 2012 would be good enough. And they were right, their civilization didn’t exist anymore in 2012. Only relevance their calendar system had in 2012 was that some people felt like it was a prophecy about the end of the world. Nope, just was an arbitrary date the Mayans rightly assumed would be far enough away it wouldn’t matter.
While I suppose you could make a date format that was infinitely expandable, it would take more processing power and is really unnecessary.
Anyway got until 2038 until we’ll have to deal with a popular date format running out of bits. We’ll probably be in some kind of mad max post apocalyptic world before then so it won’t matter.
That’s a misconception. The Maya (not Mayan, that’s the language) long count for December 20, 2012 was 12.19.19.17.19. December 21, 2012 was 13.0.0.0.0. Today is 13.0.11.7.4. It continues the same way indefinitely, it’s just the number of days since some arbitrary date (August 11, 3114 BCE if you’re curious) in base 20, with the second to last digit in base 18, which seems odd at first but it rather cleverly makes it so the third digit can stand in as a rough approximation of years, and the second is approximately a generation. Now October 13, 4772 could be seen as an endpoint but there’s nothing that says it can’t be extended with one more digit to 1.0.0.0.0.0, and then you’re good for another 150,000 years or so.
Now there was a creation myth that said 0.0.0.0.0 was the previous world’s 13.0.0.0.0, but there was no recorded belief that this was any sort of recurring cycle, in fact plenty of Maya texts predicted astronomical events millennia past 2012. The idea that it was recurring was probably borrowed from the similar Greek construct of ekpyrosis, which doesn’t specify any sort of time frame.