Live data from Hacker News

Falsehoods programmers believe about Unix time

alexwlchan.net

191–200 of 275 posts

Re: Falsehoods programmers believe about Unix time

#191
post #153
post #89

Earlier quoted context omitted.

What's the Unix Time for the UTC second 1985-06-30 23:59:60? My understanding is this physical second is not representable in unix time. How about the UTC seconds before and after that one, 1985-06-30 23:59:59 and 1985-07-01 00:00:00? My understanding is that the first is 489023999, and the second is 489024000. There is one unix second, but two physical seconds between the start of the two times.

> What's the Unix Time for the UTC second 1985-06-30 23:59:60? My understanding is this physical second That's not a physical second, it's a calendar second.

Every UTC calendar second represents a physical second.

On most days, every unix second corresponds with exactly one UTC second and they all correspond with exactly one physical second, and each one could be measured as the number of vibrations of some particular atom.

On a day with a positive UTC leap second, it's different. At 12:00:00 UTC, it's 12:00:00 unix time, the next day at 12:00:00 UTC, it's also 12:00:00 unix time; 86401 physical seconds have passed, and UTC has counted 86400 calendar seconds, one of which was a leap second, but unix has only counted 86400 seconds.

If you're running leap smearing, all of the unix seconds in that day are a little bit longer than the physical seconds (the exact details depending on your smear technique). If you're using classical techniques, 23:59:59 will be two physical seconds long, and the fractional second will reset to zero as the second physical second starts and count up again.

In contrast to UTC, and Unix Time, TAI always has exactly 86400 physical seconds per day, but after a UTC leap second, both UTC and Unix Time will be offset from TAI by an additional second.

Re: Falsehoods programmers believe about Unix time

#192
I think we should have a scientific definition of time -- something that is highly static and precise (such as the time it takes for an atom to vibrant a number of times, or the time it takes light in a vacuum to travel a certain distance) and a cultural definition of time that is more loose than UTC (There is always the same number of seconds in a day, but maybe some days have shorter seconds than other days).

Cultural time is fine and dandy for human level stuff. Keep that simple. Scientific time for business, engineering and scientific stuff.

Re: Falsehoods programmers believe about Unix time

#194
post #116
post #111

Earlier quoted context omitted.

I know it will never happen because of cultural reasons, but really, we need to separate the time (as in how I describe a point on the time scale, for, let say, a meeting, especially one that involves people in globally distributed locations), and the cultural aspect (at what time people are sleeping or eating lunch). Right now those two things are intertwined, and that's bad. Not everyone eats lunch around noon or g…

It's called UTC. You just want UTC with a different string format and a timezone format appended to it, or maybe seperate from it.

Pretty much, yes.

Re: Falsehoods programmers believe about Unix time

#196

I read articles like this and come to the conclusion that UTC is flawed, not Unix time. Leap seconds seem mostly useless. People seem to think they are important for astronomy, but for every astronomical calculation I have ever done, your first step is converting from UTC to TAI. Move any jumps in time to once a century (or millennium). Such jumps have occurred in the past (Julian to Gregorian) and are easy to handle…

Well, the problem with this is that every simplistic view at time is... well... too simple. It's not that many people haven't tried, I especially like this article: https://qntm.org/abolish That being said, why your approach doesn't work is that there are several hard astronomical or cultural definitions that you'd throw off by playing with time. A day is defined as the rotation of the earth around its axis. A week i…

>A day is defined as the rotation of the earth around its axis.

>A year is defined as the rotation of the earth around the sun.

Sounds like we need a generic geo-solar measurement.

Re: Falsehoods programmers believe about Unix time

#197
post #130
post #97

Earlier quoted context omitted.

It's a lot easier to test and prepare for something that occurs at least semi-regularly than a monumental event far into the future that is "so far into the future we don't have to worry about it"....

If we abolish leap seconds (and any other changes to UTC) and let the error accumulate until it hits 30 minutes then a 1-hour time zone change can adjust for it. Time zone changes happen at least semi-regularly so it wouldn't be monumental.

Wouldn’t that move the international date line?

Re: Falsehoods programmers believe about Unix time

#198
post #138

Earlier quoted context omitted.

Your statement is both true and misleading. The speed of the Earth's rotation is slowing over time. Therefore leap seconds are becoming more and more common. In a century, we should be averaging something like 1 a year. In 500 years, we should be averaging one every few months. And so on. It took over a thousand years for the Julian calendar to fall apart. Our current timekeeping system will also fall apart eventuall…

500 years from now, if we're still alive, enough of us will be living in space colonies rather than on the Earth's surface that the Earth's rotation will not necessarily be immediately relevant to everyone's lives. Regardless, we've had maybe half a minute of drift since the 1970's. If the drift is 1 minute in the 2000's, 1 second per year in the 2100's, 2 seconds per year in the 2200's, 3 seconds per year in the 230…

We need a pseudo day still due to our sleeping rhythms but perhaps people could choose that based on personal preference not just stick with 24h

Re: Falsehoods programmers believe about Unix time

#199
post #35

Question: would anything go wrong on a Unix system if you used TAI as your timezone, rather than UTC? TLS, maybe?

TLS doesn't care about a 30 second difference in clocks, unless you're running your certs really close to the notBefore/notAfter. There's enough broken systems out there that it makes sense to not use certs that don't have at least 24 hours of margin on either side.

Re: Falsehoods programmers believe about Unix time

#200
post #170

Earlier quoted context omitted.

Well, just to nitpick, seconds do vary in comparative length from reference frame to reference frame...and that actually does start to matter in global computing.

Seconds don't vary, your approximation of a second varies. If you want to nitpick, you're going to need to start with Cesium-133 oscillation periods as averaged from over nine billion samples.

Seconds do vary because there are no privileged reference frames in the universe. You'll get a different measurement if your cesium measuring experiment is traveling at a different speed than you are.
Post reply on HN