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

231–240 of 275 posts

Re: Falsehoods programmers believe about Unix time

#231

Post by masklinn »

dancek wrote: post #208

I've been thinking about datetime APIs and how most of them become extremely tedious when you have to account for daylight saving, countries changing time zones et cetera. I was actually planning to write my own implementation for $language using unix timestamps as internal representation and requiring a timezone whenever parsing or printing. But then I considered leap seconds. I don't know if there are libraries tha…

> I was actually planning to write my own implementation for $language using unix timestamps as internal representation and requiring a timezone whenever parsing or printing

That does not and can not work when trying to represent future local events, which is the vast majority of them as an event normally happens relative to a specific geodesic location.

Astronomical events are more or less the only ones which actually routinely get planned in TAI / TT, and astronomical software is thus the only one for which this model could actually work. And then you wouldn't be using unix timestamps (because it's UTC).

Re: Falsehoods programmers believe about Unix time

#232

Post by jillesvangurp »

TeMPOraL wrote: post #5
koala_man wrote: post #4

> But it’s unsatisfying to say “this is false” without explaining why Got my upvote. I can't stand the "falsehoods programmers believe" articles that make a point out of not backing up any of their claims.

Is this really a problem? The "falsehood programmers believe" articles I remember reading all list things that were either obvious, or obvious in retrospect.

The artcicle is confusing unix time, which is an integer that increments every second, with it's UTC representation. This representation is an interpretation of that number. In theory it could be decremented. But this has never happened. In practice what happens is that we add leap seconds, which means that we allow the UTC interpretation of the incrementing integer to have an extra second and not that we move the integer forward by two seconds.

The reason that this is not a problem is that most hardware clocks are pretty awful to begin with and need frequent automated corrections (through ntp). This does in fact cause that integer to increment/decrement locally when that happens and far more often than once every few years. This too is mostly a non issue. For practical purposes, time moves forward and when you access time using one of the many high level APIs you get a fresh interpretation of the system clock's integer. A much bigger problem would be the Y2038 problem when that integer overflows. I believe work is underway in the Linux kernel to address that.

Re: Falsehoods programmers believe about Unix time

#233

Post by pjc50 »

mehrdadn wrote: post #128
AgentME wrote: post #88

Earlier quoted context omitted.

In your case, you're not doing the specific thing I prohibited. I only meant you should never do arithmetic on a timestamp to try to "convert" it to an equivalent representation of the same instant (as Java 8 defines it) in another timezone. However you're specifically doing arithmetic on the timestamp to calculate a new different instant, which is fine. (Your case isn't that different than the user pressing a "shift…

> you should only store timestamps of past events and events that happen at a fixed instant regardless of calendars and wall clocks as Unix timestamps I think this works more often than not, but it's hardly foolproof or without repercussions. Say, you can imagine Google Calendar having a list of holidays for the US. Say it's New Year's day. You're saying you'd replicate that into 6 epoch timestamps (one per time zone…

This is a trick question - for whole-day events, the best way to handle them is to record the calendar day you want them to happen on, not the timestamps of the start and end of the day in some particular timezone. See what iCal does with DATE versus DATE-TIME (which must be UTC or include TZ): https://tools.ietf.org/html/rfc5545#section-3.3.4

Re: Falsehoods programmers believe about Unix time

#234

Post by masklinn »

max76 wrote: post #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). Cultu…

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

Business and engineering are chock-full of human-level stuff. And scientific stuff which isn't either doesn't use UTC (astronomy) or is not impacted (because it deals pretty much only with sub-day durations and everything works based on the SI second only).

Re: Falsehoods programmers believe about Unix time

#235

Post by masklinn »

tqwhite wrote: post #176

Unix time is the humber of seconds since 1970. Seconds are a physical thing. Unix time references the number of "cycles of the radiation produced by the transition between two levels of the cesium 133 atom" UTC measures time. This article is silly.

> Unix time is the humber of seconds since 1970.

It's not, and it has never been. The original unix time was "the time since 00:00:00, 1 January 1971, measured in sixtieths of a second", this got modified multiple times until it settled upon the number of UTC seconds since 1970-01-01T00:00:00Z, meaning it's non-monotonic, non-continuous, and not based on "physical" seconds.

Re: Falsehoods programmers believe about Unix time

#236

Post by Dylan16807 »

masklinn wrote: post #225
013a wrote: post #78

Earlier quoted context omitted.

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" ha…

Ah yes, the spherical cow of software development: it's much simpler to build software which interacts with nothing and especially no body .

There's definitely something to be said about overengineering though. No human is going to notice if the clocks all drift together by 1 second per year.

Re: Falsehoods programmers believe about Unix time

#237

Post by time_travlr »

Why does Unix time first travel forward one second, then go backwards one second, versus "pausing" (flat line on the graph) one second? Both have their pros and con; if the graph accurately depicts how Unix time is implemented, why was this decision made versus the other?

Re: Falsehoods programmers believe about Unix time

#238

Post by quickthrower2 »

philwelch wrote: post #211
quickthrower2 wrote: post #198

Earlier quoted context omitted.

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

The day would shift half an hour in the next 600 years. That’s half as much as it shifts twice a year for DST, except it would happen gradually over a period of time roughly equal to the time between the fall of the Eastern Roman Empire and today.

I was sort of nodding to the people who claim they have a 25 hour sleep cycle. Once we are in space and using artificial light, you can choose the sleep cycle that suits you. But predicting things in 500 year is just Sci Fi I guess!

Re: Falsehoods programmers believe about Unix time

#239

Post by Dylan16807 »

acqq wrote: post #117

The article is wrong or misleading. POSIX (and ISO) time_t is not supposed to "see" the additional leap second at all. POSIX time_t is defined to effectively always have exactly 86400 seconds per day, and no fractional parts. The seconds as defined by POSIX then can't last exactly as long as the atomic seconds. Even on the days where a leap second occur. Wikipedia article confirms: "Every day is treated as if it cont…

I really don't think POSIX intends seconds to vary in size. And while it's hard to measure the difference over a year with a typical clock, it's very easy to measure the skew over a single day. Skewing over a day is not something for only atomic clocks to worry about. And skewing over more than a day would imply that you want to get dates wrong, which is stretching the language quite a bit...

Re: Falsehoods programmers believe about Unix time

#240

Post by teddyh »

jondubois wrote: post #218
endymi0n wrote: post #36

Earlier quoted context omitted.

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…

We should abolish local time too. There should be a single time for every country which is the number of milliseconds since either the beginning of human civilization, the beginning of earth or the universe.

So You Want To Abolish Time Zones

https://qntm.org/abolish

Post reply on HN