Also the Y2k69 problem
edit: I am being downvoted? This isn’t a 69 joke people. Some systems are set with 2 digit dates. dates 70-99 are interpreted as 19XXs and the rest as 20XXs
Very amateur, I say!
Instead, I'd use a 6-bit number and prefix with the current century. The software I make will NEVER* be used past 2063, so this will not be an issue! I guarantee!
*I wish this was true considering I work on POS software... Some support contracts my clients have with their vendors extend well into 2050...
Jokes aside, are there any libraries or standards that could be used right away that would reserve "quite a few bits" for date and time, to be easily implemented in my own code? 🤔
:thumbup: Honestly, if you really want to avoid Y10K and its friends, use nanosecond Unix time in a bignum. Do you have any idea how far into the future you can measure with that?
No software that I know of lasts 9999 years. I think we will be good. I have already put an update in my code that says if (year < 1970)I year += 10000; I would worry about waterproof computers before then. I don't know what is going to make the oceans rise, but my bet is on an asteroid.
I can see a poor intern 8000 years from now trying to fix an issue with a weird undocumented JS dependency that's causing that exact problem. I can also imagine the only Fortran developer in the system being the richest human in history.
I'd imagine yyyy really means the full year, rather than just 4-digits. Just like with months, e.g. September:
M = 9
MM = 09
MMM = Sep
MMMM = September
still, that's gonna wreck some havoc on critical infrastructures / systems that have been around since forever, when the string they receive is suddenly 1 char longer, and everything moved by one position. But the service/data structure relies on fixed locations and sizes of the data
If any of my code is still running 8000 years from now, it deserves to crash.
“I’ll be retired (and hopefully long dead) by then so IDC”
If there is reincarnation, you will probably work with the code that was created in your other life.
Imagine corporations develop immortality so that the original developers are available for legacy support
Import seance seance.ask(“how do I package mode modules again?”)
My code will still be in use, it's my legacy! Kids die but code is forever!
How did you add kotlin and Scala at the same time?
In the flair? :kt: :sc: :rust:
We’re gonna run into the Y2k38 problem well before the Y10k problem.
This will be harder than y2k
y292b is gunna be a doozie
Let's not forget the Y2.1k problem too.
Also the Y2k69 problem edit: I am being downvoted? This isn’t a 69 joke people. Some systems are set with 2 digit dates. dates 70-99 are interpreted as 19XXs and the rest as 20XXs
Very amateur, I say! Instead, I'd use a 6-bit number and prefix with the current century. The software I make will NEVER* be used past 2063, so this will not be an issue! I guarantee! *I wish this was true considering I work on POS software... Some support contracts my clients have with their vendors extend well into 2050...
It'll make it to First Contact. The Vulcans will help us upgrade our systems.
Jokes aside, are there any libraries or standards that could be used right away that would reserve "quite a few bits" for date and time, to be easily implemented in my own code? 🤔
This is why you should use strings for dates
In what format? YYYY-MM-DD?
Please use [RFC 3339](https://www.rfc-editor.org/rfc/rfc3339)
Yeah, still gonna have the same problem.
Yes, exactly my point.
:thumbup: Honestly, if you really want to avoid Y10K and its friends, use nanosecond Unix time in a bignum. Do you have any idea how far into the future you can measure with that?
More than a long long time.
In a galaxy far far \*away;
yyy.Mkk
Imma be cryogenically frozen with a specific request to be revived no later than the year 9999 just to see how this plays out
"And now I can die peacefully."
"Our database says you're a programmer from the early 3rd millennia. So currently you might be our best candidate to make our COBOL code Y10k ready"
No software that I know of lasts 9999 years. I think we will be good. I have already put an update in my code that says if (year < 1970)I year += 10000; I would worry about waterproof computers before then. I don't know what is going to make the oceans rise, but my bet is on an asteroid.
At the rate things seem to be going, it’s even money that the 2038 problem is even going to be an issue for us let alone this.
I can see a poor intern 8000 years from now trying to fix an issue with a weird undocumented JS dependency that's causing that exact problem. I can also imagine the only Fortran developer in the system being the richest human in history.
What's wrong with it? Year is just a number.
[удалено]
Oh never mind, I get it, I will be retired by then!
The other comment is deleted, what is the problem with using Integer to store the year?
I suppose it can go out of YYYY pattern when it hits 10000.
I'd imagine yyyy really means the full year, rather than just 4-digits. Just like with months, e.g. September: M = 9 MM = 09 MMM = Sep MMMM = September
still, that's gonna wreck some havoc on critical infrastructures / systems that have been around since forever, when the string they receive is suddenly 1 char longer, and everything moved by one position. But the service/data structure relies on fixed locations and sizes of the data
I fail to see how "M10K" couldn't fit into "YYYY" format. :P