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

Falsehoods programmers believe about time

infiniteundo.com

Post reply on HN
Print view View original

191–200 of 212 posts

Re: Falsehoods programmers believe about time

#191

Post by mayoi »

yccs27 wrote: post #59
cgrealy wrote: post #20

Does anyone actually believe this? Even the most inexperienced developers I’ve worked with are well aware that time, and timezones in particular, are really difficult. I’ve yet to meet anyone that has suggested using anything other than a battle-hardened standard library for time.

Even if you use a library, it's easy to bake in an "obvious" assumption into your program. Such as storing location + date + time, because that should be unambiguous, right? Or confusing "same time tomorrow" with now + 24h. Are you even sure which one you need?

> Are you even sure which one you need?

Any examples of when you need "now + 24h" instead of same time tomorrow?

For example, daylight savings may start the next day, and time will be adjusted... And everything will be done 1 hour earlier than today despite the hour on the clock being "same time" as today, so what? Other than your body needing to readjust the sleep cycles, noone else seems to actually care.

Meanwhile, when I setup cron to do something daily, I don't care about this at all, so what if on one day, the interval will be 23 or 25 hours?

Re: Falsehoods programmers believe about time

#192

Post by hoseja »

rzimmerman wrote: post #183

At NASA I wrote a set of Python scripts to help with planning and telemetry for a Mars mission. I had to convert a lot of time data points between UTC and a Mars timezone/clock (specific to the rover itself). There was an officially blessed tool written in Java that ran from the command line for time conversion. It was too slow to call out for each data point, so I figured it would be generally useful to port the con…

One glorious day we'll switch to outside-of-gravity-well coordinated reference time frame.

Re: Falsehoods programmers believe about time

#193

Post by kristopolous »

BurningFrog wrote: post #166
kristopolous wrote: post #104

The "opportunity for bugs" I didn't realize until I was over 10 years into my professional career: 10 AM 11 AM 12 PM 01 PM 02 PM 03 PM I see large software systems for things like airlines and trains sometimes make this mistake, for instance a 1 hour trip on a ticket that says "11:30AM - 12:30AM" which is actually negative 11 hours. I have a collection of photos somewhere of every time I've caught it. If I could chan…

As a 1995 immigrant, I understand what am/pm time it is 22 hours of the day, but I'm still not sure about those two 12:* mystery hours. I know, I can look it up, and I have several times. But the knowledge doesn't stick...

Post median, ante median.

Translation: After midpoint, before midpoint.

Also the difference in the cycles comes from analog clocks.

I can explain all of this but it's still confusing and stupid to have to deal with it in 2022

Re: Falsehoods programmers believe about time

#194

Post by ddevault »

wruza wrote: post #114
ddevault wrote: post #84

Earlier quoted context omitted.

I think that would be out of scope for the standard library. We do have an interface which might be helpful for developing such a tool, though: https://docs.harelang.org/datetime#builder

Too bad that most stdlibs outscope it to third parties. Wildcard periods are essential for some applications (even as simple as a periodic reminder) and also are hard to do correctly. I’d say a period is actually more important than a date, because we mostly work with periods, and our “datetimes” are just integer coordinates of pixels of time, so to say.

Well, Hare is not a high-level programming language, and the standard library has a specific, finite scope. It's also not generally used in the kinds of situations where this is called for (think C -- there's not really a similar library for C, either). But that's not to say it isn't important -- I definitely think that there should be a library which provides this.

Re: Falsehoods programmers believe about time

#195

Post by afiori »

BurningFrog wrote: post #166
kristopolous wrote: post #104

The "opportunity for bugs" I didn't realize until I was over 10 years into my professional career: 10 AM 11 AM 12 PM 01 PM 02 PM 03 PM I see large software systems for things like airlines and trains sometimes make this mistake, for instance a 1 hour trip on a ticket that says "11:30AM - 12:30AM" which is actually negative 11 hours. I have a collection of photos somewhere of every time I've caught it. If I could chan…

As a 1995 immigrant, I understand what am/pm time it is 22 hours of the day, but I'm still not sure about those two 12:* mystery hours. I know, I can look it up, and I have several times. But the knowledge doesn't stick...

You have to look at it as a separate concept from the hh:mm time,

pm is between midday (inclusive) and midnight (exclusive) and am the rest, between midnight (inclusive) and midday (exclusive).

Re: Falsehoods programmers believe about time

#196

Post by noSyncCloud »

kristopolous wrote: post #193
BurningFrog wrote: post #166

Earlier quoted context omitted.

As a 1995 immigrant, I understand what am/pm time it is 22 hours of the day, but I'm still not sure about those two 12:* mystery hours. I know, I can look it up, and I have several times. But the knowledge doesn't stick...

Post median, ante median. Translation: After midpoint, before midpoint. Also the difference in the cycles comes from analog clocks. I can explain all of this but it's still confusing and stupid to have to deal with it in 2022

Ante/post meridiem, not median

https://en.wikipedia.org/wiki/12-hour_clock?wprov=sfla1

Re: Falsehoods programmers believe about time

#197

Post by yreg »

mayoi wrote: post #189
yreg wrote: post #2

Unimportant sidenote: I don't like the naming of these "falsehoods programmers believe about X" lists. Surely programmers are more likely to be conscious of these not being true than non-programmers.

No, they are not. Beyond leap years and leap seconds, I know absolutely nothing about time, how to handle all the "daylight savings" and other kind of bullshit. And I actually do not care, at all. Luckily for me, people who do care and know these things have made libraries that can handle it all while expecting only minimal knowledge from me, such as being aware that time zones exist at all.

The reason why you use those libraries is that you know time is difficult and you need to be cautious. You don not blindly believe those statements about time. If pressed to answer whether they are right or wrong you would say that you are not sure.

Re: Falsehoods programmers believe about time

#198

Post by astrobe_ »

wink wrote: post #50
astrobe_ wrote: post #41

Earlier quoted context omitted.

That's what I thought. This list mixes "falsehoods" that nobody with a bit of common sense - even children - would believe, and pedantry that could be useful to 0.001% of developers. For most programs, Time starts in 1970. IMO, this list is only good at... wasting time. Except for the multiple statements (that could be one or two) that point out that there's not such a thing like "identical clocks" and "same time on…

So "most" programs can ignore birth dates of people older than 52? I don't think so.

Most programs don't deal with birth dates and people. It's like stating that most "computers" are neither on a desktop nor in a pocket. Technically correct, as counter-intuitive as it is.

Re: Falsehoods programmers believe about time

#199

Post by mjevans »

bentcorner wrote: post #107
takinola wrote: post #94

The biggest falsehood a programmer could believe about time is that they have the ability to roll their own time manager. Just use a battle-hardened library and hope for the best. Dealing with time in code is crazy-making in a way I never expected.

I agree. I'd wager most programmers don't need to actually worry about calendars , but most occasionally need to worry about time. Just use a library and read the docs for what to expect to happen when you do something like getCurrentTime. What is the resolution, does it monotonically increase, etc. If you actually need to worry about calendars and user input, you have my sympathy.

Handing those cases correctly might very well be a Turing test...

Re: Falsehoods programmers believe about time

#200

Post by mgkimsal »

ryandrake wrote: post #175
pjscott wrote: post #154

Earlier quoted context omitted.

Agreed on all counts. The “falsehoods programmers believe about X” articles are cautionary lists of edge cases to think about, with an unfortunately aggressive naming scheme.

They should really call these lists "Incorrect assumptions programmers make about X" or: "Test cases programmers should test their software against"

Or “boundaries users have to stay within”. I’m aware of a lot of edge cases. When you start building with those in mind, it adds complications. Extra steps or more UI or whatever, to ensure the “right” thing happens, assumptions are obvious, etc.

More often than not I’m pushed back in with “that doesn’t happen” or “don’t spend time on that”. “We’re never open past 9, don’t worry about a day” but then they acquire a system in a different time zone and … boom. Things are broken.

Post reply on HN