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

171–180 of 275 posts

Re: Falsehoods programmers believe about Unix time

#171

Post by taneq »

macspoofing wrote: post #166
taneq wrote: post #161

Earlier quoted context omitted.

The core issue is that the number of days per year is messy, so it's not possible to have a 'nice' number of seconds in a day and also in a year. The best solution is probably just to use a nice number of seconds per day and accept the fact that in 100ish years summer will start in March, not December. It's not like we need to build our entire society around planting and harvest any more.

That's not anywhere close to "the best solution"

This discussion isn't going to be very meaningful unless you wanna tell us what 'best' means to you.

Re: Falsehoods programmers believe about Unix time

#172

Post by _jal »

twic wrote: post #131
bradknowles wrote: post #96

Earlier quoted context omitted.

The third principle of Continuous Delivery is "If something is difficult or painful, do it more often". So, if leapseconds are actually painful for you, then maybe we need to contemplate making this kind of adjustment on a finer timescale, like milliseconds. OTOH, if you think leapseconds are painful now, just you wait until you postpone this pain and do it even less frequently.

That principle is more of a koan than actual concrete advice. For example, deleting your entire codebase and firing all your developers is painful, but even the most continuous deliverer wouldn't advise you to do that more often.

Do you also pee in front "wet floor" signs?

Getting past pedantry, the advice is obviously about foreseeable, repeating parts of normal business, and it applies to more than devops.

A long time ago (tail end of the "desktop publishing revolution"), I was a production assistant, and then manager at a magazine. We published six times a year. Towards the end of my first year there, I realized we had the same problems, right down to our Advertising Director's emotional meltdown, every. single. issue.

After getting to know folks working at other magazines and people at our press, I noticed that the monthlies seemed to run smoother with less drama, and the weeklies were even better at it. Eventually I realized it was because they had to be. If there was some minimum amount of human drama that had to happen, it was forced into exhibitions that didn't disrupt the (tight) schedules. If last-minute changes from flakey advertisers came in, they didn't cause a firedrill, they just didn't run, because that issue is already on the press and we're talking about the issue after next now. And so on.

The general principle is actually very straightforward, and applicable all over the place, including your personal life. If you have high-friction processes, devoting time and attention to them is the way you make them lower-friction processes. And while it may be possible to do that without doing things over and over until you get there, it probably is not possible for you to get there without repetition, else you'd not have the problem in the first place.

Re: Falsehoods programmers believe about Unix time

#173

Post by saagarjha »

twic wrote: post #131
bradknowles wrote: post #96

Earlier quoted context omitted.

The third principle of Continuous Delivery is "If something is difficult or painful, do it more often". So, if leapseconds are actually painful for you, then maybe we need to contemplate making this kind of adjustment on a finer timescale, like milliseconds. OTOH, if you think leapseconds are painful now, just you wait until you postpone this pain and do it even less frequently.

That principle is more of a koan than actual concrete advice. For example, deleting your entire codebase and firing all your developers is painful, but even the most continuous deliverer wouldn't advise you to do that more often.

Doesn't every company do this slowly as they replace code and developers?

Re: Falsehoods programmers believe about Unix time

#174

Post by AgentME »

tus87 wrote: post #155
AgentME wrote: post #140

Earlier quoted context omitted.

Isn't this the opposite of what the article says?

Yes.

The article's assertion that Unix time treats days as 86400 appears correct to me. Both Python and Javascript report 12-01-2019 UTC as the Unix timestamp 1575158400, 12-01-2000 UTC as Unix timestamp 975628800, and the difference between those is 599529600, which is exactly 19*365 days + 4 leap days as 86400 second days.

The leap seconds added in 2005, 2008, 2012, 2015, and 2016 are all uncounted there. If Unix timestamps were the count of physical seconds that had passed since 1970/1/1 UTC, then the end result of my test should have been 599529605 instead of 599529600.

Re: Falsehoods programmers believe about Unix time

#175

Post by bacon_waffle »

twic wrote: post #133
jhayward wrote: post #45

Earlier quoted context omitted.

We humans almost always want our concept of "what time is it" to correspond to the relative motion of the sun in the sky. We ask "what time is sunrise?", and "when will the days start getting longer?". We like "noon" to be when the sun is highest in the sky. All those things are what UTC is designed for.

We humans, without the use of a clock, do not have the faintest idea when midday or midnight is. We can't judge when the sun is highest in the sky, and we certainly can't judge when it's lowest under our feet. The sun isn't even highest in the sky at noon! Firstly because of timezones (your noon is based on highest-sun in the middle of your timezone, not your current longitude), and secondly because of this whole epi…

I've been surprised at how "in tune" I've become to time, at times, when I've lived outside for substantial periods. Certainly it's not hard to have better than the "faintest idea" when midday or midnight is, if +/- 30 minutes qualifies? Plenty good to decide when to have lunch...

In the higher latitudes, it requires even less acclimation once you've got an idea of your orientation, and maybe what the stars look like. To the point that, at the poles, a clear sky is a direct-reading 24-hour clock.

Re: Falsehoods programmers believe about Unix time

#177

Post by bcaa7f3a8bbc »

The original purpose of Unix time was decoupling local time representation and internal timekeeping of the system. Unix time could be the "One True Time" of the system, it always increases monotonically. When you need local time, all the tricky and nasty details, including DST, mandated calendar changes, etc, are processed by the tzinfo system library/database. If the calendar has changed, at least in principle one does not and should not have to update the system clock or most unrelated applications, simply update tzinfo and you're done.

Unfortunately, Unix time did not consider the effects of leap second, which broke the very foundation of Unix time and nullified all the benefits it had. A UTC change (leap second) will force you to update the system clock.

There is a way out: we should stop keeping time in UTC, instead, we do the timekeeping in TAI. And we provide a system-wide facility called "utcinfo" database to handle TAI-UTC conversation. Just like tzinfo, but much easier, it only needs to store all the leap-second events. All problems solved! I'm aware that the leap second still causes some issues: the kernel still has to be notified for the upcoming leap second for its UTC APIs, but still better.

The question is, why don't systems and libraries treat TAI as the first-class citizen of timekeeping? Why aren't we doing it right now? Because it's incompatible with Unix time, or it's something else?

Re: Falsehoods programmers believe about Unix time

#178

Post by macspoofing »

taneq wrote: post #171
macspoofing wrote: post #166

Earlier quoted context omitted.

That's not anywhere close to "the best solution"

This discussion isn't going to be very meaningful unless you wanna tell us what 'best' means to you.

That's fair. I simply can't see the best solution relying on getting rid of deeply ingrained culutural norms that span thousands of years.

Re: Falsehoods programmers believe about Unix time

#179

Post by nitwit005 »

bcaa7f3a8bbc wrote: post #177

The original purpose of Unix time was decoupling local time representation and internal timekeeping of the system. Unix time could be the "One True Time" of the system, it always increases monotonically. When you need local time, all the tricky and nasty details, including DST, mandated calendar changes, etc, are processed by the tzinfo system library/database. If the calendar has changed, at least in principle one d…

> Unfortunately, Unix time did not considered the effects of leap second

The change to UTC to include leap seconds was in 1972, which was after unix time came into existence.

Re: Falsehoods programmers believe about Unix time

#180

Post by IggleSniggle »

gervu wrote: post #170
IggleSniggle wrote: post #146

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.

I like the cut of your jib. But I suppose what I was saying was that, for the purposes of establishing “now”, “now” isn’t really standardizable except with respect to a single inertial frame, and any time-keeping that occurs outside of this inertial frame will not be absolutely in sync, even though it may have a highly accurate measure of time for its own inertial frame.

This matters when computers are bouncing records about time around satellites and across the global.

Edit: I have no idea what I’m talking about so please do not hesitate to correct me on the particulars!

Post reply on HN