Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Falsehoods programmers believe about Unix time

alexwlchan.net

Post reply on HN
Print view View original

71–80 of 275 posts

Re: Falsehoods programmers believe about Unix time

#71

Post by lcuff »

rocqua wrote: post #65
AgentME wrote: post #46

Here's a falsehood I've seen a bunch of times: the idea that Unix timestamps need to be converted to your local timezone. Unix timestamps are the number of seconds since a specific date in a specific timezone (UTC)! If a user gives you a Unix timestamp and you know they're in the PDT timezone, you should not add or subtract 7 hours of seconds to "convert" the timestamp to UTC! It already is. Similarly, if your client…

Some probing questions: Alice and Bob both live in England and have planned a conference call at 15:00 on 4-jan. Now Alice happens to travel, and she is in American on 4-jan. What should here calendar do? Moreover, Alice also has a recurring event "Workout" every friday at 9:00, what should that shift to? Finally, it turns out Bob is also in America, what time should the conference call be at now? Finally, for some r…

I really agree, especially with "There is no universal semantics that will deal with every case." When I enter a time for an appointment, then travel to a different TZ, but know I'll be home when the meeting occurs, I have to tolerate the Macintosh calendar converting my meeting to the local TZ, then back to my local TZ, which ends up being odd at least, and confusing and annoying when it first happened.

Re: Falsehoods programmers believe about Unix time

#72

Post by pteraspidomorph »

tus87 wrote: post #31

This guy is confusing Unix time with local time. This statement: > Unix time is the number of seconds since 1 January 1970 00:00:00 UTC Is true regardless of the calender or leap seconds. Think of seconds in terms of some physical phenomena, like how many times a certain atom trapped in a crystal lattice vibrates and you see that doesn't depend on the calendar. Converting Unix time to local time obviously has to take…

If I understand what people are saying correctly, this is actually not true; leap seconds can not be referenced in Unix time and are not included in the unix timestamp value. They're just ghost seconds during which the counter stopped for one second. Which is not the way the system should have been designed, in my humble opinion. All seconds should be referenceable.

Re: Falsehoods programmers believe about Unix time

#73

Post by tus87 »

toast0 wrote: post #57
tus87 wrote: post #31

This guy is confusing Unix time with local time. This statement: > Unix time is the number of seconds since 1 January 1970 00:00:00 UTC Is true regardless of the calender or leap seconds. Think of seconds in terms of some physical phenomena, like how many times a certain atom trapped in a crystal lattice vibrates and you see that doesn't depend on the calendar. Converting Unix time to local time obviously has to take…

> > Unix time is the number of seconds since 1 January 1970 00:00:00 UTC > Think of seconds in terms of some physical phenomena, like how many times a certain atom trapped in a crystal lattice vibrates and you see that doesn't depend on the calendar Unix time is NOT the number of physical seconds since 1970 UTC. It's the number of Unix Seconds since 1970. Every day has 86400 Unix Seconds. Some UTC days have more than…

Unix seconds ARE physical seconds.

> Every day has 86400 Unix Seconds.

Except a day with a leap second in it.

> Unix time cannot represent the seconds beyond 23:59:59 on a UTC day, but otherwise attempts to match UTC.

Err...it literally represents ~49 years beyond 23:59:59 on Day1 of UTC.

Re: Falsehoods programmers believe about Unix time

#74

Post by speleo_engr »

jhayward wrote: post #55
planteen wrote: post #39

Earlier quoted context omitted.

"UTC isn't flawed, in fact the adjustments that keep it aligned to solar time are very helpful for its defined use cases." What use case in the year 2019 is made easier by UTC getting leap seconds instead of treating it as a monotonically increasing scale (TAI)? I'm genuinely interested. The only suggestion I have ever heard is use of a sextant -- what an anachronism in the modern world...

See my comment on the other reply. I'll add in; astronomers like to be able to find objects in the sky using calculations based on time. UTC (actually TT, which underlies UTC) is good for that. Spend a little time on the various wiki pages for time standards, and think about why those things exist. https://en.wikipedia.org/wiki/Universal_Time

I've spent a lot of time finding objects in the sky to high accuracy with astronomical algorithms. The first step is always converting from UTC to TAI. See Astronomical Algorithms by Jean Meeus if you don't believe me.

Your noon example works for a single longitude in a time zone and the time between subsequent noons on two different days will only be exactly 24 hours 4 times a year. It seems unnecessarily complex to push annual leap second updates to preserve something like as obscure as these 4 events for the 24 time zones exactly on the line of longitude to the accuracy of a second.

See the Wikipedia on abolishing leap seconds, "that the drift of about one minute every 60–90 years could be compared to the 16-minute annual variation between true solar time and mean solar time, the one hour offset by use of daylight time, and the several-hours offset in certain geographically extra-large time zones"

https://en.wikipedia.org/wiki/Leap_second

Re: Falsehoods programmers believe about Unix time

#75

Post by Groxx »

dooglius wrote: post #12
RcouF1uZ4gsC wrote: post #9

One thing to note is that both Google and Amazon smear out the leap seconds https://developers.google.com/time/smear so that this is no longer a falsehood on AWS or GCP. I suspect, over time, more organizations will adopt this approach.

Leap smearing makes #3 no longer false, but #1 and #2 remain false

Also worth noting that even tho it "solves" leap seconds, it does nothing to solve normal clock corrections. Clocks skew normally, and they need to be corrected eventually - nothing that I'm aware of skews across more than a couple seconds / within NTP limits.

I.e. disconnect from a time server for a few days/weeks/months/etc. When you reconnect, it could be off by seconds/minutes/hours. Odds are pretty good that your system will just jump to the correct time immediately, rather than smearing it out for like N*3x longer than the difference is.

The same is true any time you lose your internal clock, e.g. if your machine is shut down and its battery dies. If it were to skew across "all time since jan 01, 1970", it'd probably catch up well after the expected lifetime of the computer.

Re: Falsehoods programmers believe about Unix time

#76

Post by tus87 »

pteraspidomorph wrote: post #72
tus87 wrote: post #31

This guy is confusing Unix time with local time. This statement: > Unix time is the number of seconds since 1 January 1970 00:00:00 UTC Is true regardless of the calender or leap seconds. Think of seconds in terms of some physical phenomena, like how many times a certain atom trapped in a crystal lattice vibrates and you see that doesn't depend on the calendar. Converting Unix time to local time obviously has to take…

If I understand what people are saying correctly, this is actually not true; leap seconds can not be referenced in Unix time and are not included in the unix timestamp value. They're just ghost seconds during which the counter stopped for one second. Which is not the way the system should have been designed, in my humble opinion. All seconds should be referenceable.

> leap seconds can not be referenced in Unix time

UNIX time does not represent/reference calendar time, it represents the number of physical seconds since 1970-01-01UTC. How you translate that into local calendar time is up to you!

Re: Falsehoods programmers believe about Unix time

#77

Post by msla »

endymi0n wrote: post #36
speleo_engr wrote: post #14

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.

When you get into the world of programming for most people, businesses especially, a day is defined as 24 hours. We like to think that our days and months and years are tied to vast astronomical forces, for romantic reasons, but when it comes down to it, everything comes back to the second, and the second is defined to be a single unvarying length of time.

Re: Falsehoods programmers believe about Unix time

#78

Post by 013a »

jhayward wrote: post #29
speleo_engr wrote: post #14

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…

> come to the conclusion that UTC is flawed The different time definitions exist to support different use cases. UTC isn't flawed, in fact the adjustments that keep it aligned to solar time are very helpful for its defined use cases. It's just that time is complicated. If you think you will be doing time math where duration is paramount consider using TAI. PS: for all those who think 'time' is complicated in fascinat…

Well, time is complicated, but not for reasons that really matter to 99.95% of engineers (relativity and such). At its most basic level, Time is really just a monotonically increasing counter of seconds (or ms or ns or whatever). That's it.

The problem is really the cultural and societal layers on top of it. That's not Time's fault, its Our fault. A "Day" has to be 1 rotation of the earth around its axis, a "Year" has to be 1 rotation of the earth around the sun, etc.

Every unit of time at the Second and below is Simple. Every layer above it is Complex, including the counter of seconds from any date in the past, because Humans are Complex, not because Time is Complex. If we stopped caring that it always has to be cold in Winter (in the US) or that 7am is always morning (well, sunrise changes w.r.t both time and location), or that days are always (usually) 86400 seconds long, our interactions with time would be much simpler.

And, really, given that EVERY SINGLE UNIT above the second has not just some but many special case rules that are instantly confusing, maybe we should stop caring so much.

Re: Falsehoods programmers believe about Unix time

#79

Post by legohead »

I was aware of leap seconds after working for an online auction website. How to deal with all the auctions that may be ending right at or before the leap second?

Our solution was simple: temporarily pause all the auctions :)

We already had site-wide "auction pause" code as a result of people DDOS'ing the site.

Re: Falsehoods programmers believe about Unix time

#80

Post by jlg23 »

nulagrithom wrote: post #18

I don't understand this one: > If I wait exactly one second, Unix time advances by exactly one second How does UTC jumping around affect this? If a leap second is removed it doesn't mean you've waited 0 seconds. I feel like this is wrong too: > If there’s a leap second in a day, Unix time either repeats or omits a second as appropriate to make them match. It's not Unix time doing that. It's UTC.

> How does UTC jumping around affect this? If a leap second is removed it doesn't mean you've waited 0 seconds

The OP did not make this claim. He said that waiting 1s does not necessarily increase the Unix time by one second - not the other way around.

Or how my highschool math teacher put it: Every time it rains, the street gets wet. But not every time the street is wet, it rained - maybe my dog just took a leak....

Post reply on HN