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

151–160 of 212 posts

Re: Falsehoods programmers believe about time

#151

Post by UncleEntity »

not2b wrote: post #131
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…

I missed a plane flight once because an admin for the company I was working with booked a midnight flight accidentally and I thought it was at noon (I think she thought so as well). I think it was in the 90s sometime.

Not very long ago I showed up to an appointment at 7:00 am and was told it was really at 19:00 — and our computer system uses 24 hour time so obviously someone just screwed up the conversion.

Midnight appointment are interesting since the system doesn’t have “no appointment time” so they use 00:00 and 00:01 for a real midnight appointment and if you’re really, really tired…

Re: Falsehoods programmers believe about time

#153

Post by dkbrk »

Time would be much less of a problem if Terrestrial Time was used internally everywhere. That is: if TT (realized as TAI) were used as the fundamental definition of time, rather than UTC; and UTC were treated as just another timezone.

Then, there would be only three problems, which decompose nicely:

1. Trying to keep the system time accurate, and accounting for the possibility it isn't. 2. Having up-to-date time zone information 3. Converting TT to/from a date/time in some particular format in a particular timezone.

(1) is fundamentally unavoidable. (3) is complicated but well-defined. (2) should be handled by the system. All that's left is calculations on time values, which if they're in TT (i.e. actual time) are very well behaved.

Ultimately this is the fault of the standards bodies. POSIX defines time in terms of UTC. NTP tries to keep the system clock synced with UTC. Postgres "timestamp with timezone" stores UTC. Zone files state offsets in terms of UTC, and even worse, transition times are stated with reference to a timezone (see tzfile(5) and RFC 8536), which is completely insane.

This could change. Existing standards can't but new standards could be introduced to succeed the old ones and exist side-by-side. Maybe, instead of proposing changing UTC because they find leap seconds inconvenient, an organization like Facebook could actually do something useful and push for them.

Re: Falsehoods programmers believe about time

#154

Post by pjscott »

gweinberg wrote: post #140

Obviously nobody believes most of these falsehoods. Presumably the op means a lot of programmers create bugs that seem t imply programmers believe these falsehoods. But this one jumped out at me: "Any 24-hour period will always begin and end in the same day". It would be a lot more plausible if "always" were replaced with "never". Add 24 hours to a time, and it will (almost) always be the next day.

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.

Re: Falsehoods programmers believe about time

#155

Post by bee_rider »

bobbylarrybobby wrote: post #147
bee_rider wrote: post #58

We should just define a year to be 360 days long and made up of 12 30 day months. Then we can elect some druids or whatever to arbitrarily, at the start of each year, define which dates the seasonal borders will land on. Events which are truly dependent on weather can be defined in terms of "Days after the season starts." Or we could define a 5.5+-.5 day holiday between the beginning and end of a given year. Those da…

Why not 364 days, 13 28-day months, with one special day (probably New Year's Eve), two during a leap year. This would have the interesting feature that a given date always falls on the same day of the week for the duration of the year.

Then we'll have to come up with a new month name, which will cause all sorts of bikesheding.

Re: Falsehoods programmers believe about time

#156

Post by bee_rider »

_carbyau_ wrote: post #139
account-5 wrote: post #95

Earlier quoted context omitted.

I was going to mention this. 13 months each with 28 days.

bye bye Halloween...

On the other hand we'll have a whole 13'th month, which will afford us many bonus Fridays the thirteenth.

Re: Falsehoods programmers believe about time

#157

Post by Bilal_io »

vlunkr wrote: post #69
Bilal_io wrote: post #64

Earlier quoted context omitted.

Should we also turn off computers in hospitals and in other important facilities? And then how can we qualify what's important? Maybe you and I have the privilege to turn off computers for almost a week without a negative effect, but not the majority of the world, everything uses a computer to operate and coordinate. Think about food production, aviation, shipping, sailing... And much more at both small and big scale…

You're going to take issue with that instead of Druid part?

I don't mess with druids.

Re: Falsehoods programmers believe about time

#158

Post by UncleEntity »

taylodl wrote: post #52

In the U.S. falling back to standard time from daylight saving time is rough. Those days have 25 hours - and the interval from 1:00 - 2:00 repeats (you reach 2:00 and fallback to 1:00 and repeat the interval). Makes power scheduling difficult - which 1:00 - 2:00 interval are you talking about? Also, the offsets between the timezones change. Eastern Daylight Time falls back from 2:00 to 1:00 Eastern Standard Time, whi…

During the last “fall back” event I experienced the 1 o’clock hour three times since I randomly happened to cross a time zone at exactly 2:00am…or maybe 1:00am?

The worst part was I had an appointment at 02:00, somewhere where they won’t let you in if you show up too early, in the other time zone and hadn’t had to deal with daylight savings time for a good long while having lived in Arizona where they don’t deal with such silliness. Trying to figure out what time to leave to time my arrival was very difficult.

Re: Falsehoods programmers believe about time

#159

Post by bee_rider »

runarberg wrote: post #141
bee_rider wrote: post #58

We should just define a year to be 360 days long and made up of 12 30 day months. Then we can elect some druids or whatever to arbitrarily, at the start of each year, define which dates the seasonal borders will land on. Events which are truly dependent on weather can be defined in terms of "Days after the season starts." Or we could define a 5.5+-.5 day holiday between the beginning and end of a given year. Those da…

The Icelandic calendar used to be something like that before the adoption of the Gregorian calendar in the 18th century (Iceland actually skipped the Julian calendar entirely, although I believe the old calendar was actually heavily inspired by the Julian). All years were 12 months of 30 days plus 4 extra days of summer ( Sumarauki in Icelandic), making the year exactly 52 weeks. Leap years had one extra week added t…

I'm certainly romanticizing the whole thing but given,

> There is no special numbering of the years used in the Icelandic calendar, so the year may be omitted or the current Gregorian year used.

It is hard not to imagine a day in Sumarauki as being sort of magically timeless.

Re: Falsehoods programmers believe about time

#160

Post by askvictor »

madamelic wrote: post #70
LAC-Tech wrote: post #66

The system clock will never be set to a time that is in the distant past or the far future. Right but if that's the case, what exactly can you do about it?

It really depends what the 'threat model' is. If you are creating, for instance, an idle game where the user can pay to skip time; that's a problem. If you are doing cryptographic checks dependent on time, that's a big deal (eg: how do we handle when the client or service goes "wtf, no. That's the wrong time")

Have had plenty of problems with WPA-Enterprise auth refusing to join a wifi network on account of a wildly wrong computer time. Which in turn means that the computer can't get a correct time on account of not being able to ask an NTP server.
Post reply on HN