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

61–70 of 275 posts

Re: Falsehoods programmers believe about Unix time

#61

Post by rhizome »

Florin_Andrei wrote: post #50
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…

> Here's a falsehood I've seen a bunch of times: the idea that Unix timestamps need to be converted to your local timezone. That's less of a "falsehood", more of a complete misunderstanding of what Unix time is.

Yep, a faulty belief is not the same as ignorance.

Re: Falsehoods programmers believe about Unix time

#63

Post by skybrian »

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…

For most practical purposes (like knowing when to show up at a meeting), you need to know local time.

Even if you got rid of leap seconds, you still wouldn't know for sure how many seconds there are between now and some date and time in 2022 because you don't know what the local timezone will do. It's not clear why this is a useful calculation? For scheduling events in the future, you need to store the timezone (or location) and local time anyway.

Unix time is a useful approximation for comparing and converting between local times.

Re: Falsehoods programmers believe about Unix time

#64

Post by brmgb »

jhayward wrote: post #40
brmgb wrote: post #26

I deeply disagree with point 3. Unix Time actually never goes backward: it just stagnates during a leap second. The article uses fictional fractional second to argue the contrary but I don't think it makes much sense. Unix Time is represented an integer and has no concept of such a fractional unit. That's an important distinction because it means that if you use Unix Time as a timestamp you can actually be sure than…

You can set unix time to any value, including the future or past. If timestamps are recorded during those time-traveling epochs you will indeed see time go backward. Anyone writing time-aware processing needs to take this in to account, or they will eventually suffer for it.

Sure, you can manually force Unix Time to go backward but that's very different from what is argued in the article. If you do time-aware processing and mess with the clock you are using, you can except troubles. That's in no way unique to Unix time.

Still, unless you actively mess with, Unix Time actually never goes backward.

Re: Falsehoods programmers believe about Unix time

#65

Post by rocqua »

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 reason England or America decides to change the DST changeover will now happen on 3-jan.

There is no universal semantics of time that will deal with every case. Certainly 'store UTC and convert to the users's time-zone' is not universal, nor is 'store every timestamp with a time-zone'. The way people perceive of 'do this thing at this time' is very hard to capture. Moreover I'd wager no users would actually fill out time with sufficient detail to deal with this. "What do you mean UTC, time-zone, or local-time" I just wanna work out at 9:00 every day, and meet with Alice at 15:00 in a few days. I thought computers were meant to make things easy".

Re: Falsehoods programmers believe about Unix time

#66

Post by holycrapwhodat »

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…

Unix timestamps have an extremely strict definition and should not be left up to interpretation.

You're describing UI/UX challenges with calendaring and appointments. Very real issues, but separate from Unix timestamps.

Re: Falsehoods programmers believe about Unix time

#67

Post by tus87 »

aflag wrote: post #48
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…

Are you saying Unix time doesn't get adjusted when there are calendar changes in the box?

Correct. When was the last time you changed UNIX time due to summer time/daylight savings?

Re: Falsehoods programmers believe about Unix time

#68

Post by Groxx »

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.

UTC jumping around affects it if you're basing your time-elapsed measure by checking "time.now() - previouslySavedTime". That can give you a negative value, if e.g. your 1/2-second elapsed time crossed a leap second.

Re: Falsehoods programmers believe about Unix time

#69

Post by msla »

abtinf wrote: post #53

Perhaps a stupid question: Why isn't there a time standard that is monotonic and defined simply in terms of seconds, without attempting to match the movement of the earth (no leap seconds, no negative seconds, no daylight savings, no complicated calendar politics)? If such standard existed, wouldn't it be the best to use for programming, with "simple" conversions to/from the all the other standards? Basically, I want…

TAI is what you want.

Re: Falsehoods programmers believe about Unix time

#70

Post by koala_man »

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.

Take the original one about names, which claims that sometimes children don't get names.

Should I be flagging mandatory name fields as an I18N concern? How many people are affected? In which regions does this warrant UI hints or changes? Will they have names by the time COPPA stops applying?

I've casually Googled this and found nothing, so whatever point the author hoped to make was lost.

Post reply on HN