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

141–150 of 212 posts

Re: Falsehoods programmers believe about time

#141

Post by runarberg »

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 to sumarauki making it a total of 11 days and leap years exactly 53 weeks. This has the benefits that each month starts on the same day of the week (e.g. the first day of the first summer month (Harpa) is still celebrated in Iceland and always lands on Thursday).

https://time-meddler.co.uk/the-old-icelandic-calendar/

Re: Falsehoods programmers believe about time

#142

Post by IncRnd »

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

Earlier quoted context omitted.

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")

This is my issue with a lot of technical aspects of software engineering. I can read and understand about clock drift, vector clocks etc. But I sometimes struggle to align that with real world design and architecture. An IoT device reported an event happened at t=1, but t is not accurate. Ok, so? What exactly can I do about that?

In that case, the best you can hope for is to centralize time on the server. The IoT devices can keep local differential time or contact the server (or a log server or somewhere else) at the time of the event. It's kind of messy, since you are asking to trust a client's data, which is untrustworthy.

Re: Falsehoods programmers believe about time

#144

Post by IncRnd »

bennyp101 wrote: post #7

"Months have either 28, 29, 30, or 31 days." Ok, Im intrigued, are there months that don't? I assume it must be a country specific thing?

I suppose you could have 31 days plus an hour. This depends on how you are tracking time and if that includes free-running counters.

Re: Falsehoods programmers believe about time

#145

Post by IncRnd »

ccooffee wrote: post #103
suzzer99 wrote: post #92

One of the hardest programs you could ever have to write would be historical times taking into account all the time zone and Daylight Savings Time changes over the years. It might be impossible. Just look at Indiana's history with time zones and DST.

Many years ago, a user filed a bug report that the timezone information we used for historical places in Indiana was incorrect. I don't remember exactly what the user was doing, but I think it had something to do with train schedules or something. I did not fix that bug. (But I did learn that the 'TZ' database has this information, though I think 'America/Indiana/*' had been pruned out of the copy our JVM was using.)

Some of Indiana is on the Central Timezone and some is on the Eastern Timezone. This is definitely an issue!

Re: Falsehoods programmers believe about time

#146

Post by dang »

pigbearpig wrote: post #115
dang wrote: post #54

I don't know if these are all the same falsehoods, but—related: Falsehoods programmers believe about time zones - https://news.ycombinator.com/item?id=24870376 - Oct 2020 (16 comments) Falsehoods programmers believe about time (2017) - https://news.ycombinator.com/item?id=24453712 - Sept 2020 (8 comments) Falsehoods programmers believe about Unix time - https://news.ycombinator.com/item?id=19922062 - May 2019 (268 co…

Should the link be updated to the actual source? This gist appears to just be a copy of https://infiniteundo.com/post/25326999628/falsehoods-program... and https://infiniteundo.com/post/25509354022/more-falsehoods-pr... https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b...

Sure—changed from https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b... now. Thanks!

(For some reason people think we know these things)

Re: Falsehoods programmers believe about time

#147

Post by bobbylarrybobby »

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.

Re: Falsehoods programmers believe about time

#148

Post by cgrealy »

bee_rider wrote: post #55
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.

I bet you could get me to give the wrong answer to most of these questions if you worded it cleverly in informal conversation, but the answer to anything time and date related in a technical setting is "Ugh, we'll have to look up the stupid edge cases here," right?

Exactly.

And you also need to understand your timing requirements.

If all you care about is recording a date on an invoice, you really don’t need to worry about leap seconds or smearing or whatever.

Re: Falsehoods programmers believe about time

#149

Post by bobbylarrybobby »

wyldfire wrote: post #143

> The day of the month always advances contiguously from N to either N+1 or 1, with no discontinuities. I would've presumed this one - for the Gregorian calendar, at least. What are some counterexamples?

Well, if by day advancing you (they) mean adding 24 hours to a given datetime, then a 23 hour day would cause the date to advance by two.

Re: Falsehoods programmers believe about time

#150

Post by jamesfinlayson »

at-fates-hands wrote: post #102
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 personally have not had much experience with it. Would love to hear some horror stories you've encountered. It might help me keep an eye out for it.

Trying to deal with conversion between time zones or to/from daylight saving can have gotchas which libraries will deal with for you.
Post reply on HN