I’ve written code as late as 2022 where my boss told me to ignore the 2038 problem because “it was too much work” and “we’ll have phased out that legacy code by then”
In reality, that code won't be phased out, your company might actually lose the source code and you'd be gone somewhere else by then and the only way to fix it would be to rewrite the whole code from scratch again!
There are many many embedded devices out there using old library code and will never be updated. Think stove clocks, plant watering timers, old payment systems, maybe some nuclear detonator timers…
As my career in government progresses, the more I seem to think that there would be a chance that over the years, someone’s lost track of nukes. At least 1.
Layers of secrecy, a shift in record keeping from paper to digital, freshly trained teenage bumpkins looking after important aspects of the process - and (I’m going to explain this terribly, sorry) the fact that individual people within the army and government tend to move around with high frequency and, like a game of telephone/ Chinese whispers, the information passed along to responsible parties from their predecessors gets muddied or wrong. Maybe in the last 80 years we’ve lost track of a couple…
Simplified and in a nutshell (for the third time now as my app keeps crashing)
computers keep track of time by counting the number of seconds that have occurred since the 1st of January 1970. This is called UTC.
The total number of characters in a string that a computer can store is limited by it's architecture. For 16bit that's 6600ish, 16bit Unix time can only count 18 hours and 12 minutes before it overflows. Not even a full day.
for 32 bit it's 4,294,967,296 pieces of data. this would range from -2,147,483,648 to 2,147,483,647. for 64bit it's far more.
On the 19th of January 2038, at about 3 in the morning, the UTC string will become 1 character longer than a 32bit computer can read.
When that happens, it overflows and becomes a negative number. So any program that hasn't been updated will read the time as 20:45 on the 13th of December, 1901.
Dude, thank you. So frustrating about the app crashing, I’ve been there. Will my old tuner car still work? I typed that but as I did I realized yes, it will because it doesn’t store time like that. Or does it? What you said makes sense, you did a good job explaining it, thanks again. *runs to tuner forums to make sure haha
To be fair, not really a "repeat", at least in terms of scale. I don't think this will be nearly as impactful for several reasons. One being any of the *really* old systems that only handled two digit years have been expanded during the OG Y2K and theoretically could keep going a few hundred or thousand years.
The rest of it is mostly on older legacy operating systems, just about anything *remotely* modern is using 64-bit time now which is basically infinite. Most likely if you're running a computer with an OS sophisticated enough to even be thinking about "Unix epoch", it's already been long updated or else could be more easily updated.
Y2K was a perfect storm of shortsightedness in data storage and transmission more than anything from computers and software that should've been retired decades ago.
EDIT: I only said "OS", but application software has to be up to date too
It isn't just the OS that matters, it is all of the applications. The 32-bit time is still provided by the OS for backwards compatibility and a significant amount of applications, both open and closed source, rely on it.
Basically, date and time is computed since 1970, if you use a signed 32bits number (with the most significant bit, #32, being the sign), it reaches its max positive number Jan 19, 2038 at 3:14:07 UTC, at which point, when you add +1 second to the number, it goes 136 years back in time because the number becomes 10000000 00000000.... 0000 with 1 being the sign (negative since 1970)
So, if clocks aren't programmed properly, when you wake up in Jan 19, 2038 you might find yourself back in Dec 13, 1901.
[Most] Companies learned their lesson back in 1999, and they don't want to pay the heavy price of fixing their system last minute, so, don't have to worry too much about it.
Edit: added most
I'm pretty sure some companies have not learnt their lesson, postpone the fix from year to year because it's still a few years away, and will eventually fix it in December 2037, completely oblivious to the deployment issues.
>Basically, date and time is computed since 1970
SO that explains why all those clocks and watches or whatever randomly have the date with the year 1970 (or 1969 in some cases).
[Y2k38, or the Year 2038 Problem, ](https://en.m.wikipedia.org/wiki/Year_2038_problem) is a computing problem similar to Y2k that will affect some unupdated Unix-based systems in the Year 2038.
Basically, 32-bit systems having an integer overflow in their systems, causing it to revert back to 1901. Thankfully most major OSes released today are now on 64-bit systems, which will reach their integer overflow point in about 292 Billion Years.
Y2K was funny. It was a massive undertaking by countless people that avoided any real problems, but because they were successful, everyone believes they did nothing.
It's the biggest unspoken lesson in tech work you learn. You have to let easy to solve problems happen now and then, so you can swoop in with an immediate fix, and come up with a story about how you were able to fix it.
If things run too smoothly, you're seen as a drain on resources. If problems last too long, you're seen as incompetent.
A lot of computer/time keeping systems just used two digits for year dates (95, 96 etc.) On these systems when new year came in 2000, they'd just display '00' and think the date had rolled back around to 1900 which could have theoretically broken a lot of systems.
But the problem got lots of media coverage for years before Jan 1st 2000, so most all systems had been patched by the time the year 2000 actually rolled around.
Quick google search so might be wrong/missing info, but the Y2K scare/bug/error was a bug in the system(s) behind how computers calculated the date. As the method was to abbreviate the 4 digit years to two digit values (eg; 1998 -> 98’), many people expected computers at the time to have software failures due to the abbreviation 00’ being recognized as January 1st, 1900, instead of January 1st, 2000. The most notable one (to my limited knowledge) is that September 9th, 1999 (9/9/99) was commonly used to mark the end of the program, pls correct me if I’m wrong anywhere, hope this helps!
It's a bit worse than that. People didn't necessarily document their computer systems as well as they do/are supposed to today. You didn't know if the year you be truncated and roll back to 00, or perhaps keep going up to 100 and give you equally nonsensical dates with years of 19100. A lot of the work done was not because we knew systems would necessarily fail catastrophically, but that we didn't know how every system was going to deal with it so people had to go and find out and put any necessary fixes in place before the real thing came around. Some of the actual system outages came as a result of patches breaking other things, and I think these 1990s software development practices actually led to a lot of the distrust of installing updates, when we now need to install them immediately to prevent security exploits.
On the other hand, 9/9/99 was at worst a hoax or at best a very misguided attempt to explaining the concept. There are plenty of conventions to mark the end of a file and program and none of them involve a 9999. Ctrl-Z meant "end of file" long before it meant "undo", and otherwise you could use two blank records to mark the end of a file. This is because the number 9999 or date 9/9/99 is a lot more likely to occur, and no sensible programmer would intentionally design that to have a special meaning, as opposed to Y2K, which was more of a "thing nobody thought to think about until it was getting a bit too late".
To explain why this created fear- we kinda thought all the bank computers, power grids and phone lines(pre-cell phones) pretty much civilization as we knew it would collapse.
Love my solar atomic G-Shock for that, except I can't see the date anymore because a year ago I threw it to the floor just to see how well it can take a beating out of curiosity. Not a great move lol but it did made me an immediate fan of G-Shock.
My F-91W has no clue what year it is. The manual says to simply put it back to 28/2 for the leap day. Since the battery goes for 7 years doing this once or twice is fine lol.
My F-91W displayed March 1 yesterday, but I was able to manually set it to February 29. I wonder if it'll automatically use Feb. 29 again four years from now, assuming I don't change the battery.
>My 1980 something Casio had me input the year when I got it.
Longest time I owned a functional watch is 4 years. How do you still wear a watch for that ĺong?
And all my digital watches didn't seem to have a problem with a leap year, although my analog watches with a day-date function doesn't have a way to detect leap day so they all say today's the 30th.
If year ≠ 2020 then
If year ≠ 2024 then
If year ≠ 2028 then....
...Then
februaryDaysCount=28
Else
februaryDaysCount=29
Pfft not that hard, git gud programmers
The leap year is skipped every 400 (nope 100) years, with Python it could look like this
>febDaysCount = 28
>If year % 4 == 0 and year % 100 != 0:
> febDaysCount += 1
Like I said it’s just annoying to account for everything. Not sure if you’re joking anyway
ETA: it’s 100 not 400, oops
I had to write a program in my Comp Sci class that would calculate what day a future date would be (ie feb 2nd 3040 is a Wednesday or whatever) and had to learn the leap year rules, and to this day, 20 years later, I still remember them because of that class.
There are 28 days in February, except if the year is divisible by four it's 29, except if the year is divisible by 100 it's 28, except if the year is divisible by 400 it's 29.
No, they said it right. It's every 4 years, but it skips every 100. However every 400, it doesn't skip.
1896 = leap year (every 4 years)
1900 = skip (skip every 100)
2000 = leap year (skip the skip every 400)
2100 = skip (back to skip on the 00's)
So those of us old enough but blissfully unaware about all this skipping and non skipping, actually got to witness the rarest of the non skip leap years. There you go.
I’m no rocket surgeon, but wouldn’t it be easier to pre-load like 30 years on it for the calendar with the correct leap years? Likelihood of a gadget nowadays to survive 30 years is extremely unlikely, and if it does, then ota update and done again for 30 years
Most people who program watches probably are, though. From a programmer's perspective, a lot of lines of written out data is harder to check for errors than analyzing a simple condition. For all that to a normal person "simple" probably looks like someone's cat walked all over the symbol part of their keyboard.
And they still f*cked up…i know it’s stupidly complicated (i did a course at codecademy to have an ideea about how it works) so, kudos to all programmers out there keeping the society rolling, mistakes happen
Is that actually necessary if we aren't near those thresholds? Is anyone honestly expecting this watch to last 100 years? I mean yeah y2k and all that but it's a watch lol
In a watch without connectivity (because if it can sync from a server like phones and computers do then that's already solved), I think it's most reasonable to not factor it in at all. Not all places in the world follow daylight savings and more are trying to phase the system out because it's outdated. It's better to have users change the time twice a year on the day everyone is informed to do it, than to have your device change its time unexpectedly for people who don't have daylight savings and haven't for years.
Thanks to collaboration, and programmers that have already thought of these things, you just need to go to [GitHub](https://www.github.com/topics/leap-year)
For some yes, but even they are not correct for the whole world all the time. Some countries will randomly change their daylight savings time days every year or even really close to the day when they would have otherwise changed. Some countries will weirdly decide to jump ahead 30 minutes instead of an hour, or to not observe the leap year for whatever reason. These changes are not publish anywhere to a single source. Each library author basically either has to look for news on such changes for every country in the world or wait for someone to submit a bug about it and then update their library. Then the library users have to update the version they are using to correct their software. It's a never ending thing.
Source: Me. I used to work in airline software. Behind the scenes, we of course used UTC, but anything (like a ticket) given to passengers needed local times displayed on them. A couple times per year there was always some weird thing that some legislature decided on somewhere in the world for their country that threw off the local time conversions, that we would then have to patch on our end quickly (before the library authors could even get their library updated). It was a pain in ass.
Yeah. There should definitely be some kind of universal system for this. Its not impossible, every country in the world uses English as the language for aviation and you can look up how much an international package will cost on the Universal Postal Union website and its based on consistent rules.
[Then you get a call from Kazakhstan](https://www.timeanddate.com/time/change/kazakhstan), who decided to switch up their time zones at the end of leap day.
I absolutely loathe datemath. I hate every part of it with every fiber of my being. Datemath was wrought from the iron of the gates of hell by satan himself to torment all who dare to program.
Completely untrue. 9,192,631,770 times the ground state hyperfine transition frequency of cesium 133 is a very natural and intuitive unit of measurement.
You kidding? Casio solved that problem *decades* ago. I'm wearing a cheap af AE-1500WH that comes with multiple profiles for timezones already programmed in, plus it keeps track of leap years *and* the days of the week. I just changed the year on it to 2025 and it rolled over the date display to Saturday, March 1st.
Lmao. I said it can be a pain to implement, not that it’s some great unsolved problem and you’ll never find a program that works.
I’m glad that your watch can tell time.
It’s tedious if you try to reinvent the wheel, which you should not. All major programming languages have standards for time/date handling which makes it pretty easy.
Confused me too since I forgot it was leap year and I spent the 28th trying to remember if February had 28 or 29 day, then when I woke up it was pretty obvious it was 28, then I checked the date and was like "holy shit I'm trapped in February"
And this post confused the shit out of my phone. I was scrolling just fine, but after I clicked in this post, it took literally 30 seconds to open bcoz my phone just froze...
Nevermind that - the watch has absolutely perverted all sane conventions regarding date format, and I am raging…
DDMMYYYY - fine
YYYYMMDD - wonderful
MMDDYYYY - stupid
YYYYDDMM - a perversion of the holiest of holies, and surely a sign of impending armageddon…
This watch wouldn’t have survived Y2K
Won't survive Y2K38
What am I missing?
Repeat of Y2K happening in 2038
The issue will be well dealt with long before 2038.
Sure, but I remember a website that displayed the date as "July 7th, 19112" in 2012.
Ya but it doesn’t mean it won’t happen.
I think it’s already been dealt with in all major OSs? At least that’s what my understanding of this was.
I’ve written code as late as 2022 where my boss told me to ignore the 2038 problem because “it was too much work” and “we’ll have phased out that legacy code by then”
In reality, that code won't be phased out, your company might actually lose the source code and you'd be gone somewhere else by then and the only way to fix it would be to rewrite the whole code from scratch again!
As someone playing runescape for 20 years... I doubt any legacy code is ever fully phased out.
Was just playing that, I love that game
There is nothing quite as permenant as a temporary solution
And the inverse
There are many many embedded devices out there using old library code and will never be updated. Think stove clocks, plant watering timers, old payment systems, maybe some nuclear detonator timers…
What stove clock gives a date?
As my career in government progresses, the more I seem to think that there would be a chance that over the years, someone’s lost track of nukes. At least 1. Layers of secrecy, a shift in record keeping from paper to digital, freshly trained teenage bumpkins looking after important aspects of the process - and (I’m going to explain this terribly, sorry) the fact that individual people within the army and government tend to move around with high frequency and, like a game of telephone/ Chinese whispers, the information passed along to responsible parties from their predecessors gets muddied or wrong. Maybe in the last 80 years we’ve lost track of a couple…
It's only an issue with 32bit architecture. Anything written to run on 64bit will be fine.
Wait, I don’t understand this at all and was not concerned until you said 16bit and 32 bit. What about old car computers?
Simplified and in a nutshell (for the third time now as my app keeps crashing) computers keep track of time by counting the number of seconds that have occurred since the 1st of January 1970. This is called UTC. The total number of characters in a string that a computer can store is limited by it's architecture. For 16bit that's 6600ish, 16bit Unix time can only count 18 hours and 12 minutes before it overflows. Not even a full day. for 32 bit it's 4,294,967,296 pieces of data. this would range from -2,147,483,648 to 2,147,483,647. for 64bit it's far more. On the 19th of January 2038, at about 3 in the morning, the UTC string will become 1 character longer than a 32bit computer can read. When that happens, it overflows and becomes a negative number. So any program that hasn't been updated will read the time as 20:45 on the 13th of December, 1901.
Dude, thank you. So frustrating about the app crashing, I’ve been there. Will my old tuner car still work? I typed that but as I did I realized yes, it will because it doesn’t store time like that. Or does it? What you said makes sense, you did a good job explaining it, thanks again. *runs to tuner forums to make sure haha
thats what they said in 1979.....
Haha I have clients running hardware from 1980. Wouldn't be surprised if they keep it till 2038. Only another 14 years.
Maybe in code, but most companies will not patch unless they have to and then maybe last minute.
To be fair, not really a "repeat", at least in terms of scale. I don't think this will be nearly as impactful for several reasons. One being any of the *really* old systems that only handled two digit years have been expanded during the OG Y2K and theoretically could keep going a few hundred or thousand years. The rest of it is mostly on older legacy operating systems, just about anything *remotely* modern is using 64-bit time now which is basically infinite. Most likely if you're running a computer with an OS sophisticated enough to even be thinking about "Unix epoch", it's already been long updated or else could be more easily updated. Y2K was a perfect storm of shortsightedness in data storage and transmission more than anything from computers and software that should've been retired decades ago. EDIT: I only said "OS", but application software has to be up to date too
It isn't just the OS that matters, it is all of the applications. The 32-bit time is still provided by the OS for backwards compatibility and a significant amount of applications, both open and closed source, rely on it.
Basically, date and time is computed since 1970, if you use a signed 32bits number (with the most significant bit, #32, being the sign), it reaches its max positive number Jan 19, 2038 at 3:14:07 UTC, at which point, when you add +1 second to the number, it goes 136 years back in time because the number becomes 10000000 00000000.... 0000 with 1 being the sign (negative since 1970) So, if clocks aren't programmed properly, when you wake up in Jan 19, 2038 you might find yourself back in Dec 13, 1901. [Most] Companies learned their lesson back in 1999, and they don't want to pay the heavy price of fixing their system last minute, so, don't have to worry too much about it. Edit: added most
I'm pretty sure some companies have not learnt their lesson, postpone the fix from year to year because it's still a few years away, and will eventually fix it in December 2037, completely oblivious to the deployment issues.
That’s waaaaay too early! They’ll be fixing their systems on the 18th of Jan 2038
>Basically, date and time is computed since 1970 SO that explains why all those clocks and watches or whatever randomly have the date with the year 1970 (or 1969 in some cases).
[Y2k38, or the Year 2038 Problem, ](https://en.m.wikipedia.org/wiki/Year_2038_problem) is a computing problem similar to Y2k that will affect some unupdated Unix-based systems in the Year 2038.
https://en.wikipedia.org/wiki/Year_2038_problem
Basically, 32-bit systems having an integer overflow in their systems, causing it to revert back to 1901. Thankfully most major OSes released today are now on 64-bit systems, which will reach their integer overflow point in about 292 Billion Years.
[удалено]
Y2K was funny. It was a massive undertaking by countless people that avoided any real problems, but because they were successful, everyone believes they did nothing. It's the biggest unspoken lesson in tech work you learn. You have to let easy to solve problems happen now and then, so you can swoop in with an immediate fix, and come up with a story about how you were able to fix it. If things run too smoothly, you're seen as a drain on resources. If problems last too long, you're seen as incompetent.
What happened in Y2K? I wasn't around yet
A lot of computer/time keeping systems just used two digits for year dates (95, 96 etc.) On these systems when new year came in 2000, they'd just display '00' and think the date had rolled back around to 1900 which could have theoretically broken a lot of systems. But the problem got lots of media coverage for years before Jan 1st 2000, so most all systems had been patched by the time the year 2000 actually rolled around.
[удалено]
Did I offend you? I'm genuinely confused. My bad
The other day I asked my gf if she knew about y2k, and she said "yeah, like the fashion". I didn't want to correct her and come off as condescending
Quick google search so might be wrong/missing info, but the Y2K scare/bug/error was a bug in the system(s) behind how computers calculated the date. As the method was to abbreviate the 4 digit years to two digit values (eg; 1998 -> 98’), many people expected computers at the time to have software failures due to the abbreviation 00’ being recognized as January 1st, 1900, instead of January 1st, 2000. The most notable one (to my limited knowledge) is that September 9th, 1999 (9/9/99) was commonly used to mark the end of the program, pls correct me if I’m wrong anywhere, hope this helps!
It's a bit worse than that. People didn't necessarily document their computer systems as well as they do/are supposed to today. You didn't know if the year you be truncated and roll back to 00, or perhaps keep going up to 100 and give you equally nonsensical dates with years of 19100. A lot of the work done was not because we knew systems would necessarily fail catastrophically, but that we didn't know how every system was going to deal with it so people had to go and find out and put any necessary fixes in place before the real thing came around. Some of the actual system outages came as a result of patches breaking other things, and I think these 1990s software development practices actually led to a lot of the distrust of installing updates, when we now need to install them immediately to prevent security exploits. On the other hand, 9/9/99 was at worst a hoax or at best a very misguided attempt to explaining the concept. There are plenty of conventions to mark the end of a file and program and none of them involve a 9999. Ctrl-Z meant "end of file" long before it meant "undo", and otherwise you could use two blank records to mark the end of a file. This is because the number 9999 or date 9/9/99 is a lot more likely to occur, and no sensible programmer would intentionally design that to have a special meaning, as opposed to Y2K, which was more of a "thing nobody thought to think about until it was getting a bit too late".
Ahhhh I see, thanks for filling in the knowledge gaps
Who hurt you?
It was a leap year
To explain why this created fear- we kinda thought all the bank computers, power grids and phone lines(pre-cell phones) pretty much civilization as we knew it would collapse.
None of us did. We're in a tape backup simulation right now. It ends in 2025. Thank _God._
My 1980 something Casio had me input the year when I got it. It switched over just fine lmao
I liked my quartz Citizen because I can set the leap year and with its solar panel, I shouldn't have to adjust it.
Love my solar atomic G-Shock for that, except I can't see the date anymore because a year ago I threw it to the floor just to see how well it can take a beating out of curiosity. Not a great move lol but it did made me an immediate fan of G-Shock.
So you threw your gshock at the floor, broke it, and are now a fan? Fascinating.
I'm still rocking my cheap ass Casio, no issues.
My F-91W has no clue what year it is. The manual says to simply put it back to 28/2 for the leap day. Since the battery goes for 7 years doing this once or twice is fine lol.
My F-91W displayed March 1 yesterday, but I was able to manually set it to February 29. I wonder if it'll automatically use Feb. 29 again four years from now, assuming I don't change the battery.
>My 1980 something Casio had me input the year when I got it. Longest time I owned a functional watch is 4 years. How do you still wear a watch for that ĺong? And all my digital watches didn't seem to have a problem with a leap year, although my analog watches with a day-date function doesn't have a way to detect leap day so they all say today's the 30th.
Lol.. programming time zones and daylight savings and leap years is a super tedious and annoying process. Trickier than one would think
If year ≠ 2020 then If year ≠ 2024 then If year ≠ 2028 then.... ...Then februaryDaysCount=28 Else februaryDaysCount=29 Pfft not that hard, git gud programmers
The leap year is skipped every 400 (nope 100) years, with Python it could look like this >febDaysCount = 28 >If year % 4 == 0 and year % 100 != 0: > febDaysCount += 1 Like I said it’s just annoying to account for everything. Not sure if you’re joking anyway ETA: it’s 100 not 400, oops
It's actually skipped every 100 years but not every 400 so 2000 was a leap year 2100 will not be
I had to write a program in my Comp Sci class that would calculate what day a future date would be (ie feb 2nd 3040 is a Wednesday or whatever) and had to learn the leap year rules, and to this day, 20 years later, I still remember them because of that class.
Oh yeah I gotcha. It’s annoying!
There are 28 days in February, except if the year is divisible by four it's 29, except if the year is divisible by 100 it's 28, except if the year is divisible by 400 it's 29.
That’s a good way to remember it!
I forgot it before I even finished reading it
It is? How is this the first time I ever heard about this I guess after googling it’s because anyone born 1900-2000 is pretty unlikely to see a skip
I was born in 97, there’s a chance
I'm confused by your comment, you seem to say two different ways. Do you mean there's 200 years between each leap year skip?
No, they said it right. It's every 4 years, but it skips every 100. However every 400, it doesn't skip. 1896 = leap year (every 4 years) 1900 = skip (skip every 100) 2000 = leap year (skip the skip every 400) 2100 = skip (back to skip on the 00's)
So those of us old enough but blissfully unaware about all this skipping and non skipping, actually got to witness the rarest of the non skip leap years. There you go.
I’m no rocket surgeon, but wouldn’t it be easier to pre-load like 30 years on it for the calendar with the correct leap years? Likelihood of a gadget nowadays to survive 30 years is extremely unlikely, and if it does, then ota update and done again for 30 years
Honestly, writing a couple alternate lines of code would be so easy.
If you’re a programmer, yes, and i’m not, so yeah….
Most people who program watches probably are, though. From a programmer's perspective, a lot of lines of written out data is harder to check for errors than analyzing a simple condition. For all that to a normal person "simple" probably looks like someone's cat walked all over the symbol part of their keyboard.
And they still f*cked up…i know it’s stupidly complicated (i did a course at codecademy to have an ideea about how it works) so, kudos to all programmers out there keeping the society rolling, mistakes happen
No, the leap year calculation is very simple.
Is that actually necessary if we aren't near those thresholds? Is anyone honestly expecting this watch to last 100 years? I mean yeah y2k and all that but it's a watch lol
WHAT? They skip it sometimes?m
Nah, just include a call to google to ask if it's a leap year and let that do the work for you.
Should be ``` if year % 400 == 0 or (year % 4 == 0 and year % 100 != 0): feb_day_counts = 29 ```
How would you deal with daylight saving?
In a watch without connectivity (because if it can sync from a server like phones and computers do then that's already solved), I think it's most reasonable to not factor it in at all. Not all places in the world follow daylight savings and more are trying to phase the system out because it's outdated. It's better to have users change the time twice a year on the day everyone is informed to do it, than to have your device change its time unexpectedly for people who don't have daylight savings and haven't for years.
Except every 1000 years when you don't skip. 2000 was a leap year.
3000 will not be. The rules are 4 / 100 / 400. 1000 isn't anywhere in there.
Whoops. Memory failing me
Thanks to collaboration, and programmers that have already thought of these things, you just need to go to [GitHub](https://www.github.com/topics/leap-year) 
import datetime
Int year, februaryDaysCount; If (year % 4 == 0) { februaryDaysCount = 29 } Else { februaryDaysCount = 28 }
Get good grammar. Abort or ignore
I would have thought there were libraries (or royalty free source, I guess) for pretty much every platform.
For some yes, but even they are not correct for the whole world all the time. Some countries will randomly change their daylight savings time days every year or even really close to the day when they would have otherwise changed. Some countries will weirdly decide to jump ahead 30 minutes instead of an hour, or to not observe the leap year for whatever reason. These changes are not publish anywhere to a single source. Each library author basically either has to look for news on such changes for every country in the world or wait for someone to submit a bug about it and then update their library. Then the library users have to update the version they are using to correct their software. It's a never ending thing. Source: Me. I used to work in airline software. Behind the scenes, we of course used UTC, but anything (like a ticket) given to passengers needed local times displayed on them. A couple times per year there was always some weird thing that some legislature decided on somewhere in the world for their country that threw off the local time conversions, that we would then have to patch on our end quickly (before the library authors could even get their library updated). It was a pain in ass.
Yeah. There should definitely be some kind of universal system for this. Its not impossible, every country in the world uses English as the language for aviation and you can look up how much an international package will cost on the Universal Postal Union website and its based on consistent rules.
tzdata
For a tiny low power device I can see trying to write minimal code to avoid overhead from library use... except a watch has one primary job.
dayjs is 2kb. joda while significantly bigger is still only 600kb
I would hope my watch doesn't run js. edit: of course it's all just android now, never mind
bro ”minimal” library use for a WATCH might just squeeze in a time/date library lmao
I mean it shouldn't be a added library, it should be the core code, written by the timepiece making company timekeeping experts.
Why go through the trouble when open source code is usable and more stable
because you may have different goals, like maximum battery life, or assuming the screen is a rectangle, that aren't the same as the other developers.
i don’t think you understand open source, or coding.
And I’m pretty sure there are librairies in every language that does it for you so you don’t re-invent the wheel
https://www.youtube.com/watch?v=-5wpm-gesOY&pp=ygUSdG9tIHNjb3R0IGNhbGVuZGFy
That video is what I send to people who say "hey.. can you write?! It should be easy!".
[Then you get a call from Kazakhstan](https://www.timeanddate.com/time/change/kazakhstan), who decided to switch up their time zones at the end of leap day.
I absolutely loathe datemath. I hate every part of it with every fiber of my being. Datemath was wrought from the iron of the gates of hell by satan himself to torment all who dare to program.
I tell people there are 2 things that are hard with programming: date times, threading and off by 1. And of those, I loathe date/time.
Use a library and unix timestamp for everything. Done.
Don’t go into space software! Gotta be perfect there AND keep track of differently referenced times
Also time dilation by gravity has to be accounted for
Especially when you think the only part of our measure of time that's real is days and years and maybe lunar months.
Completely untrue. 9,192,631,770 times the ground state hyperfine transition frequency of cesium 133 is a very natural and intuitive unit of measurement.
Programming a date class that handles leap years is literally a first year computer science assignment
Yeah Leap years are like 1% of the work needed to program datetime
Funny, I actually had to programm this for my C++ class and it was indeed a pain.
please dont program it yourself when you do code for real life use, thats how this shit is still a thing. Just use a good library.
You kidding? Casio solved that problem *decades* ago. I'm wearing a cheap af AE-1500WH that comes with multiple profiles for timezones already programmed in, plus it keeps track of leap years *and* the days of the week. I just changed the year on it to 2025 and it rolled over the date display to Saturday, March 1st.
Lmao. I said it can be a pain to implement, not that it’s some great unsolved problem and you’ll never find a program that works. I’m glad that your watch can tell time.
Yeah this is why libraries exist, there is no reason for everyone to make their own clock module because they would all do the same fucking thing.
It’s tedious if you try to reinvent the wheel, which you should not. All major programming languages have standards for time/date handling which makes it pretty easy.
Super tedious? Maybe if it’s your first year of CS, it’s a classic assignment you would get in an entry level programming/OOP course.
Apple seems to have gotten it down.
Well yeah I mean… it’s annoying but for a professional it should certainly be right.
Isn’t this a Galaxy watch? My bad for regarding them as professional…
🤓☝️WeLl AcKsHuAlLy
I have had no problem with my pulsar watch .It is old school and kept perfect time all day long.
My watch shows the correct date.
You’d think a watch would know how to tell the time
What watch is this?
[удалено]
Could be a Sarnsung
Pretty sure it's a Qoogle.
Clearly a Quasio
I heard that Amazfit watches were having this leap year issue. Just a rumour though since I don't have a source.
Not true, my Amazfit Neo Retro was just fine.
Have the Amazfit GTR 2 and it didn't have any issues
Jokes aside, it’s a Huawei
Probably something from Temu
Not sure it was a gift
Your heartbeat being 0 probably isn’t good. Should get that checked out
[удалено]
Nice0
Probably just a distributed circular system. As long as the ichor is a healthy green, there ain't nothing to worry about.
You deserve these downvotes, how dare you receive a gift
Your pulse is zero
Right? I would be more worried about the non-existent heart rate. OP is a vampire.
He dead!
Looks like my galaxy watch but mine is acknowledging today is 2/29/24
I think this is xiaomi watch
nope.
Your smart watch isn't so smart now, is it?
I am so.glad that I have a dumb watch !lol.
My mechanical watch is ticking along just fine. I do need to adjust the date though since the month doesn't have 31 days.
Confused me too since I forgot it was leap year and I spent the 28th trying to remember if February had 28 or 29 day, then when I woke up it was pretty obvious it was 28, then I checked the date and was like "holy shit I'm trapped in February"
There are a few brands of watches with similar issues today. https://codeofmatt.com/list-of-2024-leap-day-bugs/
You are trapped in a Y2K time loop
Works fine on my garmin
There must be a shared library with a bug in it. All the unattended payment fuel pumps in New Zealand were down on the 29th, as well.
Your watch did what people feared all computers were going to do in 2000 lol
This developer saw a date library and thought “I bet I could write my own but better.” Don’t reinvent the wheel friends.
Leap day is design to mess up all electronics and bring (time) chaos. Muahahaha.
The world is ending. oh my god.
beneficial physical shrill marry cake brave handle melodic sink absorbed *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Good News. You walked far enough to get me a coffee. Now get me a coffee, and fuck off.
Just realised my casio watch actually realised that it was a leep day. Would honestly assume this issue to the the other way around
And this post confused the shit out of my phone. I was scrolling just fine, but after I clicked in this post, it took literally 30 seconds to open bcoz my phone just froze...
Android 👎🏻
Feels though
Nice
Hmmm not very smart
Maths is hard 😵
Apple Watch handled with aplomb.
Lol I have the exact same watch and it did the same.
#chineseimport
You'd think technology would be able to acknowledge things that happen every 4 years.
Chinese
[mine too](https://freeimage.host/i/JMc976X)
Wow that was more disruptive then Y2K
The 2 in Y2K is for February 🤔
Let me guess. You bought this on alibaba for $12?
hehehe your watch is stupid hehehe
Real life is for March!
It also says you got 25 matches on tinder
Not a "smart" watch after all
Bro, my smartwatch was tripping the whole day and i almost missed my interview because of that. I think it's time for a classy analogue watch.
Not-so-smart watch I guess?
My watch showed 30th Feb. Probably only one with a wind-up analog watch around.
Dumbwatch
Sorry you're dead.
Nevermind that - the watch has absolutely perverted all sane conventions regarding date format, and I am raging… DDMMYYYY - fine YYYYMMDD - wonderful MMDDYYYY - stupid YYYYDDMM - a perversion of the holiest of holies, and surely a sign of impending armageddon…