7 ms·
Can't help but agree with 80% of this post but strongly disagree with the solution. This feels like a hack that punts the problems to the future. UTC has the l
by 0xCMP 4y ago
Can't help but agree with 80% of this post but strongly disagree with the solution. This feels like a hack that punts the problems to the future.
UTC has the leap second cause it's not "real time" and so now we're just gonna never sync up UTC to real time at all? How is that the solution? Either we deal with leap seconds or we need to implement something that can't go backwards and properly models time. Leap seconds seem much simpler...
In the end we didn't get rid of SQL cause of SQL Injection. We fixed the frameworks and promoted the solutions. We may simply need to make a push for languages and etc to just properly support time and promote how to do things correctly. It honestly seems easier.
- IshKebab 4y ago> This feels like a hack that punts the problems to the future. I think that's ok if "the future" is 1000 years in the future!
- jasonwatkinspdx 4y ago> we need to implement something that can't go backwards and properly models time There simply is no definition of solar time that can obey this constraint long term, because the rotation of the earth varies, and varies over time in ways we have a limited ability to predict. This is the entire crux of the problem.
- ncmncm 4y agoIt is not the crux of any problem, except for, uniquely, astronomers. But they have their own solution we need pay exactly zero attention to. Leap seconds in UTC are just as big a nuisance for them as for everyone else. They have TAI, sidereal time, and this dumb bastard UTC with its own hacked up thing that doesn't match their precise alternative.
- cryptonector 4y agoIt's not a problem for astronomers. It's a problem for everyone. It's a small problem for everyone today. And it will remain a small problem for a long time. Eventually it will not be a small problem. Meanwhile, making sure everyone agrees as to the kind of time they're talking about it hard enough.
- ncmncm 4y agoEverybody has already settled on UTC. All we need is for UTC not get fucked every 15 to 30 months and break about half the systems that need to communicate with each other. If they stop announcing leap seconds, everything correctly equipped for leap seconds will still work, and everything else that gets it wrong every time will also work. And those of us who have to make the stuff that works right adapt to all the crap that doesn't and can't be fixed can do other things, instead.
- thrown_22 4y agoPeople had agreed on GMT before that. Because we kept getting hit with bugs related to day light saving people invented UTC instead. We have IAT if you want a monotonic measure of time: https://en.wikipedia.org/wiki/International_Atomic_Time https://en.wikipedia.org/wiki/International_Atomic_Time Use the right tool for the right job. UTC is what it is. Trying to redefine it is as stupid as redefining a foot so 3 feet are a meter exactly.
- ncmncm 4y agoYou seem to have missed that everyone is already on UTC, and will not change to satisfy your sense of esthetics. Fixing UTC by simply not declaring any new leap seconds eliminates all problems. What used to break on a semi-regular basis stops breaking. Nobody suffers. Nobody pays. No problems surface.
- occoder 4y agoHaving read a lot of the comments here, I tend to agree with you. Leap seconds have not sit well with me ever since I learned about them. Messing with the number of seconds in a certain minute a few times a year just seemed ... unclean. So if fellow commenters are right, that without leap seconds it would take 6667 years for the time to drift just one hour, then leap seconds are absolutely more trouble than their worth, and we should drop it this instant and try to come up with a solution for that leap hour in the next six milleniums.
- jjoonathan 4y agoI'd argue that TAI has far more right to the term "real time" than UT1. The Earth's wobbling and halting deceleration should not impact, let alone underly, our definition of time. UTC agrees with this assessment almost always: it tracks TAI except for leap seconds that prevent it from de-syncing too far from UT1. TAI > UTC > UT1 That said, the hard work to build out a compromise has already been done, so whatever, let's just keep it until political or speed-of-light issues make it awkward to distribute information about leap seconds, at which point dropping them will be an easy and natural solution.
- pixl97 4y ago> The Earth's wobbling and halting deceleration should not impact, let alone underly, our definition of time. Who's definition... the whole relativeness of time means this is a problem. Yea, I agree that we should have a unit of time defined for things near sea level and not moving very fast. But even that becomes problematic over 'long' periods of time as the earth is slowing down and will skew from what humans experience, of which has been the basis of how we define time until recently. Even then we're still leaving out the problems of things in space and on other planets. At the end of the day we're attempting to define time as something exact for all observers, and when you attempt to give an exact definition to something that is not exact problems are going to occur.
- msla 4y agoIt's natural to distinguish between wallclock time and duration time; or, time used to fix events chronologically and time used to figure out how long to do something. The first kind of time is the only plausible use case for leap seconds, because if you insert a leap second into the command "run main motor three seconds" you're going to be in a lot of trouble.
- deleted 4y ago[deleted]
- mrighele 4y ago> The Earth's wobbling and halting deceleration should not impact, let alone underly, our definition of time If you define time in terms of days and years, I.e in term of revolutions of the earth around the sun and itself, of course it’s wobbling and deceleration has an impact. If you think it shouldn’t then measure time differently, for example as seconds since a certain instant
- turminal 4y ago> In the end we didn't get rid of SQL cause of SQL Injection. We fixed the frameworks and promoted the solutions. I mostly agree with you, but this is a bad example. SQL injection is sadly still very far from a solved problem.
- moron4hire 4y agoNo, SQL injection is a solved problem. There are just poorly trained/idiotic/lazy developers who don't use the solution.
- naikrovek 4y agoyou sound far too confident in that answer for it to be the actual correct answer.
- 988747 4y agoDatabase drivers for mabny programming languages have something like Java's PreparedStatement which allows you to compile the SQL query together with code, before the application is ran. Whatever input is provided later by the user cannot result in SQL injection, because it is not parsed/compiled at all. So yes, SQL injection is a solved problem, it's up to you whether you know about/use the solution.
- im3w1l 4y agoThe issue is that the type system doesn't enforce that the query is a literal / bundled resource.
- tremon 4y agoThe SQL language is not flexible enough to allow preparation of every possible query, so the problem is fundamentally not solved. To take a simple example: query parameters are not supported in DDL or DCL statements, and in DML queries the usage of parameters is limited to values only: even such a simple thing as an ORDER BY clause cannot be controlled by parameter insertion. "We have solutions for the most common occurrences" is not the same as "the problem is solved".
- wyuenho 4y ago> This feels like a hack that punts the problems to the future. We've already done this before, it's called the Gregorian Calendar.
- hannasanarion 4y agoUTC with leap seconds already does this. Leap seconds don't go backwards, they just alter the number of seconds in a minute. When the leap second passes, you have a minute with either 59 or 61 seconds in it. The problem described in the article where "time goes backwaards" only exist when you compare two different time sources, which is always risky, whether a leap second is happening or not.
- ncmncm 4y agoFalse. UTC is a count of seconds. Conversion to HMS is dictated to fool with the S field, but everybody suffers. The seconds count is supposed to actually skip.
- fanf2 4y agoUTC is not a count of seconds, because the standard representation of UTC does not have enough information to give you the right count. You also need to know the leap second table to convert a pair of UTC times to an accurate interval.
- ncmncm 4y ago...which would be fixed if they just stopped inserting any more. Because nobody is going to fix the million programs and gadgets that get it wrong every time.
- alerighi 4y agoBecause we are still correlating time with the rotation of the earth. Time is an absolute measure, a second is defined as a precise amount of time, and you can count the time that one event with that measure. Only historically the second was defined as a fraction of the day, and was correlated to the speed of the rotation of the earth, to this days we have better ways to define it. Who said that time needs to be in sync with rotation of the earth? Nobody, who cares? It's a so small variation happening in a so long period of time to not be noticeable to any practice use: it's not that we take the sun as a reference of time anymore! We can keep counting time as we want and not be bothered with something not precise as the rotation of the earth. And for the applications that require that sort of precision, and only them, adjust the time accordingly. I mean, a meter was once defined as the one ten-millionth of the distance from the equator to the North Pole along a great circle. It's not that for this reason if the distance between the North Pole and the equator changes we are all throwing away our meters... it's just that we found a more precise definition of one meter. Same happened with the second (and all the time measures, such as a day): we express them in a new format where it no longer matters what the earth and the sun do.
- ok_dad 4y ago> Who said that time needs to be in sync with rotation of the earth? Nobody, who cares? Humans sleep, usually at night time, and the rotation of the Earth defines night in any location, so regardless of the continual tick of some sort of "universal clock" we need a way to measure daily events that humans can use that rely on the sun going up and down at certain times and thus we need to adjust our local Earth times based on it's rotation. Maybe we can decouple UTC (or whatever) from local times completely, so then a leap second is just a second we add to or remove from the offset for any given location, but we still need to deal with adjusting local clocks to the rotation of the Earth and it's orbit around our star, the "Sun".
- nullc 4y ago> Humans sleep, usually at night time This seems like a kind of navel gazing point, however-- without leapseconds it would take on the order of 4000 years to slip an hour, quite a big longer so that nights hours aren't aren't at night. We already have a good mechenism for matching local sun time-- timezones. I don't see anyting in your post to justify one second level offsets. (aside, UT1 is technically defined in terms of earth's orientation with respect to distant quasars, not the sun :) )
- afiori 4y agoJust by virtue of living in very irregular timezone (with sometimes DST) wall clock time is often 2-3 hours off solar time. We could wait enough leap seconds to reach 30 minutes and then have a smaller (or bigger) DST timejump and nobody would notice.