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

61–70 of 212 posts

Re: Falsehoods programmers believe about time

#61

Post by saalweachter »

SwiftyBug wrote: post #33

> A week (or a month) always begins and ends in the same year Okay, of course a week can begin in an year and end in the next, but how exactly would a month not begin and end in the same year?

Depends on your calendar!

Presidential proclamations are signed and dated in two calendars, "the year of our Lord", and "the year of the Independence of the United States of America":

IN WITNESS WHEREOF, I have hereunto set my hand this twenty-fifth day of October, in the year of our Lord two thousand twenty-one, and of the Independence of the United States of America the two hundred and forty-sixth.

The former uses January 1st as the start of each new year; the latter, July 4th.

In England, Lady Day (March 25th) was the turnover of a new year, for about 6 centuries.

Re: Falsehoods programmers believe about time

#62

Post by r00fus »

mnw21cam wrote: post #49

> Britain uses GMT. Which Outlook in particular seems to get direly wrong. I have lost count of the number of times I have been sent an email from someone using Outlook containing a supposed calendar event in summer which declares that it is at a particular time GMT. It's wrong, and if I were to turn up at the time it stated, I would be an hour late.

Britain uses GMT only during winter. In summer it's BST (British Summer Time). The fact that calendar clients can't determine a timezone for a given jurisdiction on a given day is actually something that I hate.

https://en.wikipedia.org/wiki/British_Summer_Time

Re: Falsehoods programmers believe about time

#63

Post by RcouF1uZ4gsC »

Is it just me, or does anybody else hate these "Falsehoods programmers believe about..." lists.

Every abstraction at some level is leaky. Even the atom is a leaky abstraction, and maybe even matter itself is a leaky abstraction at some level.

What matters is how well the abstraction matches your use case, and where the leaks are.

Just having a list of how a particular abstraction leaks without any context is not super helpful, IMO other than conveying a sense of complexity (and perhaps a sense of looking down on those unwashed masses who believe these "falsehoods"),

Re: Falsehoods programmers believe about time

#64

Post by Bilal_io »

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…

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 scales.

Re: Falsehoods programmers believe about time

#65

Post by ddevault »

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-time-in-hare/

    // Hare's first commit.
    let hare = mbc::new(chrono::MTC, 0, 0218,10,19, 09,20,53,344357297)!;
    fmt::println(mbc::bsformat(buf, mbc::STELLAR, &hare)!)!;
    // 0218 Perseus 19, Fri 09:20 MTC
My current litmus test goal for it is to get strftime to print out 23:23:60.

Re: Falsehoods programmers believe about time

#67

Post by NeoTar »

WhyNotHugo wrote: post #17
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?

September 1752

Or October 1582, Or December 1582,

Or any of a number of different dates depending on where you were located: https://en.m.wikipedia.org/wiki/List_of_adoption_dates_of_th...

Re: Falsehoods programmers believe about time

#69

Post by vlunkr »

Bilal_io wrote: post #64
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…

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?

Re: Falsehoods programmers believe about time

#70

Post by madamelic »

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

Post reply on HN