Live data from Hacker News

Falsehoods programmers believe about time

infiniteundo.com

81–90 of 212 posts

Re: Falsehoods programmers believe about time

#81
post #74
post #28

Earlier quoted context omitted.

Clicking through the links, this post appears to be the source: https://news.ycombinator.com/item?id=4128470 As another commenter noted, the exception appears to be September 1752. That's a fun example but whether it's worth worrying about is another question...

As the comments to that comment points out, 1752 is only for one specific country . All countries switched at different times (and a few even switched back and forth a few times). Greece, in particular, seems to have switched as late as 1923 .

Russia is a big one too, especially for early 20th century history nerds.

They used the Julian calendar until after the Revolution, so when reading accounts of, say, most of WW1, Russian sources have dates that are 13 days off from Western sources. This leads to much confusion when authors don’t make it clear they’ve converted the dates (or not).

Amusingly, one of the first casualties of this was the October Revolution, which in the new (Gregorian) calendar actually occurred on November 7th

Re: Falsehoods programmers believe about time

#82

We're developing a new date/time library from scratch for Hare. So far I think we're doing a pretty good job. The person leading up this effort (Byron Torres) has written up a blog post about it here: https://harelang.org/blog/2022-04-17-chronology-in-hare/ To stress test our implementation (and to flex on other languages), we're implementing Martian time in it as well. https://harelang.org/blog/2022-08-01-martian-ti…

Skimming through it I didn’t see my common question of such libraries: can it handle approximate dates?

Twice in my career I’ve had to implement code to handle concepts like “August 2022”, or “1pm”, where it was important to track the level of precision offered by the source material for later comparisons. “1pm” is not the same as “1:00:00.000”, nor is “August 2022” the same as “20220801T00:00:00.000Z”.

Re: Falsehoods programmers believe about time

#83

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

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?

Re: Falsehoods programmers believe about time

#84

We're developing a new date/time library from scratch for Hare. So far I think we're doing a pretty good job. The person leading up this effort (Byron Torres) has written up a blog post about it here: https://harelang.org/blog/2022-04-17-chronology-in-hare/ To stress test our implementation (and to flex on other languages), we're implementing Martian time in it as well. https://harelang.org/blog/2022-08-01-martian-ti…

Skimming through it I didn’t see my common question of such libraries: can it handle approximate dates? Twice in my career I’ve had to implement code to handle concepts like “August 2022”, or “1pm”, where it was important to track the level of precision offered by the source material for later comparisons. “1pm” is not the same as “1:00:00.000”, nor is “August 2022” the same as “20220801T00:00:00.000Z”.

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

Re: Falsehoods programmers believe about time

#85

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…

https://qntm.org/calendar

See also: https://qntm.org/continuous and https://qntm.org/abolish

Re: Falsehoods programmers believe about time

#86
post #10

> There are always 24 hours in a day. Is this referring to leap seconds or what do the mean?

23hs or 25hs during DST transitions are the most obvious exception (twice a year in many many countries).

Sometimes 22hrs or 26hrs if traveling by ship.

Re: Falsehoods programmers believe about time

#90
Oh I have a great one:

> days don't overlap

If you ever have the pleasure of working with the Jewish religious calendar, it defines day boundaries by sundown and rise of the first star, which are not simultaneous. This leads to a phase during which two days co-exist. And of course it's not continuous over the year and by location.

Post reply on HN