Hacker News Reader

Comment by 0xCMP | Hacker News Reader

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.

View on HN

I'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.

> 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.

It'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.

> 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

> If you think it shouldn’t then measure time differently, for example as seconds since a certain instant

Isn’t that what the article is arguing we do? What practical benefit does keeping this historical definition of time give us? Outside of people trying to account for the rotation of the earth precisely who could even notice?

Sounds like it would be massively simpler for the users who need to use time like this to deal with leap seconds rather than require that all software deal with it all the time

It would take thousands of years for UTC-without-leaps to shift an just an hour. Our timezones are often wider than an hour.

If you really need a 'solar-ish' time, you could also define a fixed function correction for UTC->'solar' and then extend that thousands of years by an order of magnitude. (Sadly the SI second is somewhat far off from the 1/86400th of a solar day, so a big portion of the correction caused by leapseconds is just this predictable portion of the difference).

> If you think it shouldn’t then measure time differently, for example as seconds since a certain instant

Plenty of stuff would love to do that, but we distribute UTC. To get back to "time from an instant" given UTC you have to know about and correctly and consistently handle leapseconds. It's quite tricky, because when an interface hands you UTC you don't know if the latest leapsecond has been processed in it. It's getting even harder recently because the widespready distributed systems failures caused by leapseconds are causing some people to deploy varrious kinds of "leap smear" which smears out leapseconds over some number of hours. Interfaces that are supposed to return UTC now sometimes return leapsmeared UTC with some unknowable choice of smearing scheme.

Arguably the root issue is that we've based out computer timekeeping hierarchy on UTC instead of TAI (or GPS time or whatever non-leaping thing). Had we based everything on atomic time and handled 'UTC' as a presentation layer thing like timezones are normally handled things would work much better. Unfortunately that ship has really sailed. Fortunately, if leap seconds are just not issued essentially everything keeps working without issue for hundreds if not thousands of years.

> Our timezones are often wider than an hour.

The handling of timezones and of leap-seconds are orthogonal problems, arising from distinct causes. Leap-seconds are a response to the desire to synchronise an atomic timescale with the uneven rotation of the Earth; timezones (and DST) are strictly a political problem.

Politicians often don't understand the consequences of timezone changes; they often introduce them without giving enough time for people to update their timezone database - sometimes just a few days. The result is that the new timezone is nothing more than a political gesture, because hardly anyone is using it.

UTC 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.

False.

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.

UTC 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.

...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.

> 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.

It 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.

It'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.

Everybody 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.

People 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

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.

You 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.

Having 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.

If you don't want leap seconds use TAI. If you do want leap seconds use UTC.

This is like people saying that we shouldn't have daylight savings so we should redefine GMT to not have DST. That is not only stupid but breaks all use cases where you care about historical DST.

This is why we have UTC, it's GMT - DST. People in 1960 could figure this out. Are we so incompetent that our grandfathers were better programmers than us?

Hint: GMT does not, in fact, have DST. It doesn't even have Summer Time.

Crap programmers' grandparents were no better than they are. We live with it all. All their code doesn't work right and won't be fixed.

But, stop breaking it with leap seconds, and it will stay not broken.

> 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.

No, SQL injection is a solved problem. There are just poorly trained/idiotic/lazy developers who don't use the solution.

you sound far too confident in that answer for it to be the actual correct answer.

Database 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.

The issue is that the type system doesn't enforce that the query is a literal / bundled resource.

The 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".

>you sound far too confident in that answer for it to be the actual correct answer.

What kind of non-argument is that?

> What kind of non-argument is that?

the "comment" kind.

Depends if you define a solved problem as a problem with a known solution (theory) or as a problem people still pay the cost for in the wild (practice).

>> solved

Oof classic 3rd rail for when you're arguing with CS grads

CS grads don't like being generalized, I knew that

Nah. Show me evidence it is "solved".

That is what makes it a good example: SQL injection is still a million problems that would need to be fixed in a million places, and will never be.

Leap seconds are a nuisance and source of bugs in a million programs. Fix them here, fix them there, it will always be wrong in the majority.

Anything Injection has a well defined solution of "properly escape parameters". deciding how time should be represented is a completely different issue.

Just 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.

> This feels like a hack that punts the problems to the future.

We've already done this before, it's called the Gregorian Calendar.

Because 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.

> 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".

> 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 :) )

Well at least engineers in 6022 will have job security dealing with the leap hour!

That could be just a timezone switch, which our geopolitics seems to like to subject us to frequently in any case.

Sleep is not influenced by a second before or more. And I never understood this, it's far simpler to adjust the time you wake up/go to work/go to bed/whatever than to adjust the clocks.

These solutions (including daylight saving time, timezone, etc) were probably a good solution where the clock were local and it didn't exist the problem of synchronizing clocks all around the world. But to these day, it doesn't really make a lot of sense sense. Even timezone, it would be far easier knowing that there is only a world clock (UTC) and we adapt our time to the clock and not change the clock.

Timezone, daylight saving, and leap seconds generate a ton of problems only for a minor convenience...

> 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!

Reply on news.ycombinator.com