I’ve written GPS-derived clock syncing routines before. Accounting for max slew rate and doing adjtime for minor adjustments (< 300ms) with soft-slew, vs hard jumps when the delta is too big for soft/gradual adjustment. Rule of thumb is, if there are multiple time-sensitive programs or daemons running, in your system, yanking around the clock is a wonderful way to introduce non-deterministic errors that sometimes can never be replicated. You can imagine for scientific instruments, this can be a nightmare if relying on system clock. And who can forget about programming in leap seconds lol - I had the chance to actually put that 2016 leap into code and was pretty stoked about it. One way we get around this in time/safety critical systems is to send your current MCU/CPU clock count to other nodes so that they have a backup for actual real-time clock info on the other nodes. Alternatively, a PTP based system can fetch you sub microsecond (sometimes less than 10ns) sync. Time is fun when you’re a nerd. 😊 Personal story/opinion aside, excellent video. I like it when you cover these kinds of topics.
It’s so naive to say, ‘just restart it’ but I know that these big systems are like a Turing take on the power grid. Maybe this is an indication that we should allow things to have some downtime…
GPS itself does not use leap seconds, but the ephemeris does note the number of leap-seconds since 1980 (when the GPS clock started). So if you look at time as floating down from the sky vs. UTC, it is about 18 seconds off right now. (It's also neat to note that the GPS measurement of the Greenwich meridian is about 100 meters off since the earth is not a perfect sphere, and the only place in the world that the GPS lat/long exactly matches the world's lat/long is the Applied Physics Laboratory on Johns Hopkins Road in Scaggsville, Maryland, where they codified how GPS works.)
I am at awe regarding your content and the way you explain things. I used to be a DEV, now I'm an analyst Business/functional ... thin line. I am from the time when COBOL and RPG were the big thing 😀So yeah, I had a big transition going from Soap to REST to ... Anyway, ridiculing myself as it moves too fast. These vids help me a lot. Your channel should have all DEV's as subscribers. Nicely done (did I make that clear ...).
@@codingwithdee As a very old Old, I have often wondered, based on your off-the-cuff, but still wry snark, if you aren't some sort of weird Gen-X vampire who maintains a youthful appearance by feeding off the knowing chuckles of despairing devs. 😂
This reminds me of a HP Media Centre PC I had, around 2004. With a TV tuner card, it was SUPPOSED to record TV shows like a VCR. As a PC it worked well enough, but the record function would FAIL HARD twice a year. At the start, and end, of Daylight Savings Time.
Those are the times when my charts would go screwy in MRTG. So I set the servers to all use UTC, and just told everyone they would have to get used to it. And I still run all my servers on UTC, just to avoid the DST headaches.
It seems like leap seconds originally became an issue because atomic clocks kept time far more accurately than the rotation of the earth. It could be said that our measurements time became so accurate with atomic clocks that we noticed minor irregularities in the rotation of the earth.
Neat topic! I'll have to see what breaks next time a leap second is added. On the cosine description, I commend you for trying to explain that to your audience, but if they didn't get it from the equation at the start, I'm not sure they are going to get it after walking them through all the pre-calculus steps.
One thing that breaks is that occasionally there are local or UTC times like 13:59:60 which is one second after 13:59:59 but one second before 14:00:00. Since leap seconds are unpredictable, it is impossible to write a function that checks whether a date-time is valid. It must accept "13:59:60", even if there was no leap second at that time. Another thing that breaks is when you want to compute the date and time that is 1'000'000 seconds ahead from now; or how many seconds there will be between 00:00:00 jan 01 of 2025 and 2029. That depends on how many UTC leap seconds there will be in that interval -- which no one knows (not even the IAU).
I wonder, if they could use a Smoothstep function like 3x^2-2x^3 (properly stretched) instead of a cosine one? It looks almost identical and has the same values and derivatives at it's ends.
Isn't there a way to query the atomic clock and get an updated time daily weekly or even monthly? Then use this to adjust the program by resetting the current time?
No, no! There is *no* technical justification for the UTC leap seconds. Quite the opposite, they only make accurate time computations not only awkward, but downright impossible -- as you note. Applications that need accurate time do NOT use UTC. They use a straight count of seconds since some arbitrary moment in the past (the "epoch") as recorded by atomic clocks. Leap seconds are relevant only when that atomic time has to be displayed as a traditional date format: year, month, day, hour, minute, second. And there *is* a time standard (ATI, Atomic Time International) where *every* day has 24 hours, each with 60 minutes, each with 60 seconds - without any leaps. But before atomic clocks, the global standard of time was Greenwich Meridian Time (GMT) defined so that 12:00 noon was when the sun was right on top of the meridian that went through Ye Royal Greenwich Observatory, in some year-averaged sense. After the second was redefined as so-many periods of some spectral wavelength, and thus slightly different (but much more constant) that 1/24/60/60 of a GMT day, the Ye Royal morons at IAU insisted that 12:00 UTC should be as close as possible to the sun passage over Ye Royal Mudhole. Hence the leap seconds. There is *no* real advantage in this hack. The zero meridian of longitude is firmly fixed at Ye Royal Spyglass Hut, and the duration of the day varies over the year because of the Earth's elliptic orbit, so the sun at 12:00 UTC is *not* when the sun crosses the zero meridian, but only close to it. The leap seconds only reduce the discrepancy from 14 seconds to ~0.5 second *average* over the year; not to zero seconds. Again, any application that requires accurate time (like timestamping files) should avoid UTC and use straight seconds count.
Don't get me started on time zones - currency conversions is bad enough. Fortunately, I only have to deal with one time zone although us folks at the coast is definitely shortchanged during winter.
I guess it mostly needs to be patched at the main NTP servers and most of the world's infrastructure will sync, hopefully. I m surprised google used a cosine instead of a sigmoid which seems more standard to me
What a load of carry on from Google, rather than just fixing the code that was fixated on seconds never exceeding 59. Adding all that kludge rather than fixing the underlying problem. It's not like they are a small company that just has to live with software as supplied, heck, they are responsible for the whole Android system, so fixing really low level issues should be no problems to them. I was surprised that Reddit was listed as a major company..... Just more social type carryon, just turn off their boxes at 59:55 then restart at 00:05, then blame a DOS attack etc. for the blip in availability.
Maybe computers should follow a different system for measuring time, like some even with "constant" speed as the decay of some radioactive materials, and have algorithms to "translate" this measuring system to our human concept of time. Too crazy idea? maybe.... but at least we would not depend on these artificial fixes for measuring time.... :)
Ironically, Astronomers and Atomic Clocks don't use UTC for this reason. Considering these are the 2 groups who actually care about 'what time it is' and 'where the Sun is' makes the whole concept of a leap second a little ironic and sad as society prematurely optimized time to match the Sun in a way that makes a unusable system. International Atomic Time is used for atomic clocks and most scientific applications that need precise global timing, it's the system UTC is based on and just don't have the offset. Over very long periods of time, the Earth's rotation slows down as verified by the locations where measured historical solar eclipses, the Moon stealing angular momentum, and mass shifting. This is not uniform but averages at the day length increasing by 1.8ms/century. This translates into the average number of leap seconds in a year increasing by 1 every 150 years. No long term time system is going to be able to preserve the absolute length of a second with the number of seconds in a day and precise position of the Sun on the timescales of a thousand years without breaking badly. Fortunately, this is a problem that's very easy to ignore for centuries. If we never did leap seconds, in the year 2300 the Sun rise is going to be 5 minutes off from when someone today would see. That delta is the same as this week to next week. Even if we ignore it for a thousand years the cumulative difference is about 1 hour so then it'd be easier to just shift the timezone with the first leap hour. These would increase in frequency, but even after 50K years they'd only happen once a decade as a day approaches a whole second longer. Bigger problem's going to be keeping friendly numbers for total seconds in a day. 86,400 has many prime factors. But humans are bad with big numbers so you need an hour and minute replacement that is friendly. You can't do that for the next few dozen digits since their prime factorization is terrible. Imagine working with a 86,401 seconds long day which is going to be expected in 50K years where the only factors are 7 and 12,343. The next factoring friendly number is 86,436 so unless humans become very good at math in their heads something is going to break.
So maybe this is just because I've never had to tackle it from the same pov, but I never understood why leap seconds needed to be used this way. Since the NTP (and whatever the new protocol is I can't remember) are already used for correcting time, I assume there must already be mechanisms in place for correcting the clock if the updated time differs by a second or more, and if that is the case, then Why. The. F@$# do you need something as stupid as having the clock show 60 seconds (the C standard at least does show that the second might even be 61 as well). In that case it should just be as simple as correcting the UTC time by 1 second, then having that change propagate as a normal time update. That was my assumption for a long time, even before I heard of leap seconds, as I assumed there must be a way of handling large time corrections. Since that apparently is not the case, I think this really means there is a fundamental flaw in the time keeping system, if a large deviation in a time update has the potential to bring the entire internet to it's knees. I think the leap smear needs to be applied both upstream and downstream. If the UTC team needs to make a correction to the clock, it should be smeared over a period of time. Likewise, when a computer updates it's clock, I don't see any reason why it should also not go ahead and make the change gradually over a period of time. There's no reason why that couldn't be integrated as a part of the interrupt handler that deals with clock updates.
You're totally right. Leap seconds are completely unnecessary. It solves no problem but adds a new one. No one would be upset that the sun rises one second earlier this year on the mid summer. We shouldn't have leap seconds. We shouldn't even have leap minutes. We should just disconnect time from the rotation of the Earth. Time zones would migrate maybe a minute in a few centuries. In few centuries we hopefully have a new way of keeping time. Like in a century we will all be using UTC like computers already do. No more confusion about time when we have to coordinate meetings and such with people working all over the globe.
Smearing the time is a bad solution because you are literally changing the length of a second. Even if slightly, this has the potential to mess up a lot of precise scientific calculations. Imagine saying the speed of light is a constant... except on this Tuesday when it will speed up by 0.0012% because the second is longer. OK that's maybe a silly example, but it is a bad solution that has its own problems. The solution is to get rid of leap seconds and just deal with the problem in a few hundred years when the drift becomes noticeable to most people, who probably wouldn't notice anyway because even over a lifetime the change won't be that obvious. If you are doing astronomy or expecting the sun to be in a particular place at a particular time you are probably already adjusting for differences in location and seasons. Leap seconds probably make that more complicated, not simpler.
The leap second is an inane idea. We use U1 or U2 when we care about the rotational position. The notation of mm:ss has nothing to do with that -- it's a simply a way to write TAI time in a way humans can us e it. You cannot redefine the minute!
Yup, is too complicated mathematically, so os it that can function properly. I do like Google’s mathematical formula, tho, it does make a lot of sense, but it can be used negatively by digital pirates and hackers. Other than that, don’t know why not just adjusting that second manually like the hour time change and or instead of counting up to 60 why not just double count a zero second twice and or at the one second twice, that would a lot simpler solution to the leap second and I’m sure it won’t mess anything up, THAT up to 60 second count should have never happened. Cool cheat-chat, me love and intersting tooic that I just learned about, thanks! 😺🥰👩💻🕛✨💎
Having the same second twice could make even a bigger mess. I have seen things like that happen on servers, when they were disconnected from the Internet for a while, then when reconnecting, the time sync corrected the internal clock drift. Warnings from multiple daemons "the clock went backwards!"
Interesting, not an expert in the field, how about starting the leap second at -1 second? Would that be a positive solution, other than counting up to that actual number 60 leap second.
@@TheDigitalOne most software doesn't deal well with anything other than 0 to 59 seconds. Negative seconds would probably kill most software, as it would not be considered valid. I don't know about the internal code, but I don't think that things like PHP and MySQL would consider those -01 or +60 seconds valid. Since WordPress uses both of those technologies ( though it can use other database software) it seems like they could cause a lot of websites to crash. Many other CMSs use them as well.
@@javabeanz8549 seems like most software needs to be enhanced, tuned up to include the leap second, other than that Google’s applied formula would be the best option. How often does the leap second need to be added again? Is is the same time frame as the leap year? Thanks for your input!
@@TheDigitalOne end of June or end of December is a standard date for it, but it's not all the time. And I do like the solution Google's team came up with, it's rather slick, and wouldn't shift log timestamps significantly, and the shift is predictable, as it's a formula. Languages and Date/Time packages would have to be designed to deal with these kinds of issues. But, I don't know how predictable they are. I like the GPS style that was mentioned, still the same, but with an offset indicator.
Math... gross. After the first time there was an issue with the 59 becoming a 60, I'm compelled to wonder why the solution wasn't resetting the last 59 second mark of the day to 59 seconds again? Then keep on ticking like normal?
ruclips.net/video/1E5GKh1OUoY/видео.html 😁 Actually I just wanted to watch a video while playing (or cheesing?) Elden Ring and this one popped up. But it's interesting. 😀
“Expect the unexpected” is the eleventh commandment for every developer.
I’ve written GPS-derived clock syncing routines before. Accounting for max slew rate and doing adjtime for minor adjustments (< 300ms) with soft-slew, vs hard jumps when the delta is too big for soft/gradual adjustment. Rule of thumb is, if there are multiple time-sensitive programs or daemons running, in your system, yanking around the clock is a wonderful way to introduce non-deterministic errors that sometimes can never be replicated. You can imagine for scientific instruments, this can be a nightmare if relying on system clock. And who can forget about programming in leap seconds lol - I had the chance to actually put that 2016 leap into code and was pretty stoked about it.
One way we get around this in time/safety critical systems is to send your current MCU/CPU clock count to other nodes so that they have a backup for actual real-time clock info on the other nodes. Alternatively, a PTP based system can fetch you sub microsecond (sometimes less than 10ns) sync. Time is fun when you’re a nerd. 😊
Personal story/opinion aside, excellent video. I like it when you cover these kinds of topics.
It’s so naive to say, ‘just restart it’ but I know that these big systems are like a Turing take on the power grid. Maybe this is an indication that we should allow things to have some downtime…
We time nuts are a strange bunch, but our clocks never disagree with each other.
@@chrisroode A machine circadian rhythm.
Ha! 😮
GPS itself does not use leap seconds, but the ephemeris does note the number of leap-seconds since 1980 (when the GPS clock started). So if you look at time as floating down from the sky vs. UTC, it is about 18 seconds off right now. (It's also neat to note that the GPS measurement of the Greenwich meridian is about 100 meters off since the earth is not a perfect sphere, and the only place in the world that the GPS lat/long exactly matches the world's lat/long is the Applied Physics Laboratory on Johns Hopkins Road in Scaggsville, Maryland, where they codified how GPS works.)
Hmmm,, interesting information 😮😮😮
I am at awe regarding your content and the way you explain things. I used to be a DEV, now I'm an analyst Business/functional ... thin line. I am from the time when COBOL and RPG were the big thing 😀So yeah, I had a big transition going from Soap to REST to ... Anyway, ridiculing myself as it moves too fast. These vids help me a lot. Your channel should have all DEV's as subscribers. Nicely done (did I make that clear ...).
Thanks for the support, and it's always nice to hear from people with interesting backgrounds!
@@codingwithdee As a very old Old, I have often wondered, based on your off-the-cuff, but still wry snark, if you aren't some sort of weird Gen-X vampire who maintains a youthful appearance by feeding off the knowing chuckles of despairing devs. 😂
"Nosferatude"
Thank you for triggering leap-second flashbacks. Dealing with those is a nightmare.
Scrum Master causing stress eating 😂😂
Story points == fatty liver
This reminds me of a HP Media Centre PC I had, around 2004. With a TV tuner card, it was SUPPOSED to record TV shows like a VCR.
As a PC it worked well enough, but the record function would FAIL HARD twice a year.
At the start, and end, of Daylight Savings Time.
Those are the times when my charts would go screwy in MRTG. So I set the servers to all use UTC, and just told everyone they would have to get used to it. And I still run all my servers on UTC, just to avoid the DST headaches.
It seems like leap seconds originally became an issue because atomic clocks kept time far more accurately than the rotation of the earth. It could be said that our measurements time became so accurate with atomic clocks that we noticed minor irregularities in the rotation of the earth.
Just discovered your channel, subscribed- I wish you luck on your RUclips path to millions 😊
Neat topic! I'll have to see what breaks next time a leap second is added. On the cosine description, I commend you for trying to explain that to your audience, but if they didn't get it from the equation at the start, I'm not sure they are going to get it after walking them through all the pre-calculus steps.
One thing that breaks is that occasionally there are local or UTC times like 13:59:60 which is one second after 13:59:59 but one second before 14:00:00. Since leap seconds are unpredictable, it is impossible to write a function that checks whether a date-time is valid. It must accept "13:59:60", even if there was no leap second at that time.
Another thing that breaks is when you want to compute the date and time that is 1'000'000 seconds ahead from now; or how many seconds there will be between 00:00:00 jan 01 of 2025 and 2029. That depends on how many UTC leap seconds there will be in that interval -- which no one knows (not even the IAU).
So, in leap second day, Google has increasingly inaccurate time the whole day, until it ends and then itś on time again...
Amazing video as always! Its so fascinating how something do small can take down huge systems, lets hope datetime module in python handles it for me 😂
Clearly, the Earth is adjusting its spin speed to troll us.
And today that +1 sec happened 😉
Thanks for taking me back to school with the math lesson.
I wonder, if they could use a Smoothstep function like 3x^2-2x^3 (properly stretched) instead of a cosine one? It looks almost identical and has the same values and derivatives at it's ends.
This is niiice content. Just one second and kaboom, power surge
Great video. When i saw the math equation, i didn't even try to read it. But the explanation was so good, even i understood it 😜
You're a nerd!
... and I'm a nerd, and everyone watching this video is a nerd. Nerd pride!
Isn't there a way to query the atomic clock and get an updated time daily weekly or even monthly? Then use this to adjust the program by resetting the current time?
No, no! There is *no* technical justification for the UTC leap seconds. Quite the opposite, they only make accurate time computations not only awkward, but downright impossible -- as you note.
Applications that need accurate time do NOT use UTC. They use a straight count of seconds since some arbitrary moment in the past (the "epoch") as recorded by atomic clocks. Leap seconds are relevant only when that atomic time has to be displayed as a traditional date format: year, month, day, hour, minute, second. And there *is* a time standard (ATI, Atomic Time International) where *every* day has 24 hours, each with 60 minutes, each with 60 seconds - without any leaps.
But before atomic clocks, the global standard of time was Greenwich Meridian Time (GMT) defined so that 12:00 noon was when the sun was right on top of the meridian that went through Ye Royal Greenwich Observatory, in some year-averaged sense. After the second was redefined as so-many periods of some spectral wavelength, and thus slightly different (but much more constant) that 1/24/60/60 of a GMT day, the Ye Royal morons at IAU insisted that 12:00 UTC should be as close as possible to the sun passage over Ye Royal Mudhole. Hence the leap seconds.
There is *no* real advantage in this hack. The zero meridian of longitude is firmly fixed at Ye Royal Spyglass Hut, and the duration of the day varies over the year because of the Earth's elliptic orbit, so the sun at 12:00 UTC is *not* when the sun crosses the zero meridian, but only close to it. The leap seconds only reduce the discrepancy from 14 seconds to ~0.5 second *average* over the year; not to zero seconds.
Again, any application that requires accurate time (like timestamping files) should avoid UTC and use straight seconds count.
Don't get me started on time zones - currency conversions is bad enough.
Fortunately, I only have to deal with one time zone although us folks at the coast is definitely shortchanged during winter.
Thus was precient, just Crowdstrike got their first
I propose renaming "Crowdstrike Falcon" to "Slapd*ck Leghorn." Questions? Comments?
I ❤ proper nerds - great channel.
I guess it mostly needs to be patched at the main NTP servers and most of the world's infrastructure will sync, hopefully. I m surprised google used a cosine instead of a sigmoid which seems more standard to me
Why can’t they just not run anything during that adding of 1 second. And just update the clock. Then start running again after the update of clock?
actually you channel is pretty, fun :D
sub
What a load of carry on from Google, rather than just fixing the code that was fixated on seconds never exceeding 59.
Adding all that kludge rather than fixing the underlying problem. It's not like they are a small company that just has to live with software as supplied, heck, they are responsible for the whole Android system, so fixing really low level issues should be no problems to them.
I was surprised that Reddit was listed as a major company..... Just more social type carryon, just turn off their boxes at 59:55 then restart at 00:05, then blame a DOS attack etc. for the blip in availability.
Maybe computers should follow a different system for measuring time, like some even with "constant" speed as the decay of some radioactive materials, and have algorithms to "translate" this measuring system to our human concept of time. Too crazy idea? maybe.... but at least we would not depend on these artificial fixes for measuring time.... :)
Ironically, Astronomers and Atomic Clocks don't use UTC for this reason. Considering these are the 2 groups who actually care about 'what time it is' and 'where the Sun is' makes the whole concept of a leap second a little ironic and sad as society prematurely optimized time to match the Sun in a way that makes a unusable system.
International Atomic Time is used for atomic clocks and most scientific applications that need precise global timing, it's the system UTC is based on and just don't have the offset.
Over very long periods of time, the Earth's rotation slows down as verified by the locations where measured historical solar eclipses, the Moon stealing angular momentum, and mass shifting. This is not uniform but averages at the day length increasing by 1.8ms/century. This translates into the average number of leap seconds in a year increasing by 1 every 150 years. No long term time system is going to be able to preserve the absolute length of a second with the number of seconds in a day and precise position of the Sun on the timescales of a thousand years without breaking badly.
Fortunately, this is a problem that's very easy to ignore for centuries. If we never did leap seconds, in the year 2300 the Sun rise is going to be 5 minutes off from when someone today would see. That delta is the same as this week to next week. Even if we ignore it for a thousand years the cumulative difference is about 1 hour so then it'd be easier to just shift the timezone with the first leap hour. These would increase in frequency, but even after 50K years they'd only happen once a decade as a day approaches a whole second longer.
Bigger problem's going to be keeping friendly numbers for total seconds in a day. 86,400 has many prime factors. But humans are bad with big numbers so you need an hour and minute replacement that is friendly. You can't do that for the next few dozen digits since their prime factorization is terrible. Imagine working with a 86,401 seconds long day which is going to be expected in 50K years where the only factors are 7 and 12,343. The next factoring friendly number is 86,436 so unless humans become very good at math in their heads something is going to break.
Earth, why don't you spin at a constant rate?!!
Because math is not reality? 😂
The organization who added that leap second should be banned and pay the damages !
So maybe this is just because I've never had to tackle it from the same pov, but I never understood why leap seconds needed to be used this way. Since the NTP (and whatever the new protocol is I can't remember) are already used for correcting time, I assume there must already be mechanisms in place for correcting the clock if the updated time differs by a second or more, and if that is the case, then Why. The. F@$# do you need something as stupid as having the clock show 60 seconds (the C standard at least does show that the second might even be 61 as well). In that case it should just be as simple as correcting the UTC time by 1 second, then having that change propagate as a normal time update.
That was my assumption for a long time, even before I heard of leap seconds, as I assumed there must be a way of handling large time corrections. Since that apparently is not the case, I think this really means there is a fundamental flaw in the time keeping system, if a large deviation in a time update has the potential to bring the entire internet to it's knees.
I think the leap smear needs to be applied both upstream and downstream.
If the UTC team needs to make a correction to the clock, it should be smeared over a period of time.
Likewise, when a computer updates it's clock, I don't see any reason why it should also not go ahead and make the change gradually over a period of time. There's no reason why that couldn't be integrated as a part of the interrupt handler that deals with clock updates.
You're totally right. Leap seconds are completely unnecessary. It solves no problem but adds a new one. No one would be upset that the sun rises one second earlier this year on the mid summer. We shouldn't have leap seconds. We shouldn't even have leap minutes. We should just disconnect time from the rotation of the Earth. Time zones would migrate maybe a minute in a few centuries. In few centuries we hopefully have a new way of keeping time. Like in a century we will all be using UTC like computers already do. No more confusion about time when we have to coordinate meetings and such with people working all over the globe.
Smearing the time is a bad solution because you are literally changing the length of a second. Even if slightly, this has the potential to mess up a lot of precise scientific calculations. Imagine saying the speed of light is a constant... except on this Tuesday when it will speed up by 0.0012% because the second is longer. OK that's maybe a silly example, but it is a bad solution that has its own problems. The solution is to get rid of leap seconds and just deal with the problem in a few hundred years when the drift becomes noticeable to most people, who probably wouldn't notice anyway because even over a lifetime the change won't be that obvious. If you are doing astronomy or expecting the sun to be in a particular place at a particular time you are probably already adjusting for differences in location and seasons. Leap seconds probably make that more complicated, not simpler.
The leap second is an inane idea. We use U1 or U2 when we care about the rotational position. The notation of mm:ss has nothing to do with that -- it's a simply a way to write TAI time in a way humans can us e it. You cannot redefine the minute!
1:10 Funny but oh so true
This is the part I'll send to any customers 8:30, specifically customers who says I can do it free online
7:32 :D neeeeeeerd, I like being a nerd tho. Its cool
Yup, is too complicated mathematically, so os it that can function properly. I do like Google’s mathematical formula, tho, it does make a lot of sense, but it can be used negatively by digital pirates and hackers. Other than that, don’t know why not just adjusting that second manually like the hour time change and or instead of counting up to 60 why not just double count a zero second twice and or at the one second twice, that would a lot simpler solution to the leap second and I’m sure it won’t mess anything up, THAT up to 60 second count should have never happened. Cool cheat-chat, me love and intersting tooic that I just learned about, thanks! 😺🥰👩💻🕛✨💎
Having the same second twice could make even a bigger mess. I have seen things like that happen on servers, when they were disconnected from the Internet for a while, then when reconnecting, the time sync corrected the internal clock drift. Warnings from multiple daemons "the clock went backwards!"
Interesting, not an expert in the field, how about starting the leap second at -1 second? Would that be a positive solution, other than counting up to that actual number 60 leap second.
@@TheDigitalOne most software doesn't deal well with anything other than 0 to 59 seconds. Negative seconds would probably kill most software, as it would not be considered valid. I don't know about the internal code, but I don't think that things like PHP and MySQL would consider those -01 or +60 seconds valid. Since WordPress uses both of those technologies ( though it can use other database software) it seems like they could cause a lot of websites to crash. Many other CMSs use them as well.
@@javabeanz8549 seems like most software needs to be enhanced, tuned up to include the leap second, other than that Google’s applied formula would be the best option. How often does the leap second need to be added again? Is is the same time frame as the leap year? Thanks for your input!
@@TheDigitalOne end of June or end of December is a standard date for it, but it's not all the time. And I do like the solution Google's team came up with, it's rather slick, and wouldn't shift log timestamps significantly, and the shift is predictable, as it's a formula. Languages and Date/Time packages would have to be designed to deal with these kinds of issues. But, I don't know how predictable they are. I like the GPS style that was mentioned, still the same, but with an offset indicator.
There is no pause between you sentenses, really stressfull to listen to!
Math... gross.
After the first time there was an issue with the 59 becoming a 60, I'm compelled to wonder why the solution wasn't resetting the last 59 second mark of the day to 59 seconds again? Then keep on ticking like normal?
Sounds like a Saffa accent.
of course
❤️👍
You're a nerd! I bet you're a nerd too! Guess what? I'm also a nerd. We're all nerds here.
third
dee dee bb
Dee: Do these videos in a bikini and you'll crash the interent >:)
First!
ruclips.net/video/1E5GKh1OUoY/видео.html 😁 Actually I just wanted to watch a video while playing (or cheesing?) Elden Ring and this one popped up. But it's interesting. 😀