Live data from Hacker News

Falsehoods programmers believe about time

infiniteundo.com

91–100 of 212 posts

Re: Falsehoods programmers believe about time

#91
> GMT and UTC are the same timezone.

I got one for OP, too: UTC is not a timezone in the first place [1].

> UTC is not a time zone, but a time standard that is the basis for civil time and time zones worldwide. This means that no country or territory officially uses UTC as a local time.

The difference is subtle, but a standard is not subject to government whims while a timezone is.

1. https://www.timeanddate.com/time/gmt-utc-time.html#:~:text=U....

Re: Falsehoods programmers believe about time

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

Re: Falsehoods programmers believe about time

#93

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 Maya did this. Those last 5 orphaned days of the year were considered very bad luck. You did not want to be born in that period.

Re: Falsehoods programmers believe about time

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

Re: Falsehoods programmers believe about time

#95

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…

Something very similar already exists (in theory): https://en.wikipedia.org/wiki/International_Fixed_Calendar Kodak used to run on this calendar.

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

Re: Falsehoods programmers believe about time

#96

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

Adoption of the Gregorian calendar [1] resulted in a number of short months in a bunch of countries. Different but related, 46 BC, the year of adoption of the Julian calendar, had 15 months [2]. [1]: https://en.wikipedia.org/wiki/Adoption_of_the_Gregorian_cale... [2]: https://www.uh.edu/engines/epi2364.htm

I suppose it depends on if you think about a “fact month”, that is the series of days people experience, or the formal calendar months as the things being handled by the system.

The daylight savings time transition doesn’t “shorten” or “lengthen” the day, it merely transforms the clock. The day isn’t 25 hours or 23 hours. This is essentially the same thing as the Julian/Gregorian swap. The day didn’t really change, just the system we use to understand what day it is.

The span of time users experienced was weird, but this wasn’t the unit of time being shorter or longer. It’s an artifact of the transition not anything happening to the time.

A lot of these falsehoods on the list can be side stepped by distinguishing between the dimensions and the facts about representing time.

Re: Falsehoods programmers believe about time

#97

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…

This sounds like an excellent first step into imperial units.

Re: Falsehoods programmers believe about time

#98

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…

And why do only people born within them get special hats? Maybe you and I have the privilege of going about hatless, but not the majority of the world.

First they came for the Special Hats, but I did not speak out -- because I was hatless...

Re: Falsehoods programmers believe about time

#99

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

> If you are creating, for instance, an idle game where the user can pay to skip time; that's a problem.

This statement is also true in isolation.

Post reply on HN