Falsehoods programmers believe about time | Hacker News Reader

Falsehoods programmers believe about time

gist.github.com

28 pointsb800h19 comments

"A week (or a month) always begins and ends in the same year."

Obviously a week doesn't always begin and end in the same year, but, that a month might not is a new one for me, can someone give me an example?

(Turns out this one was sourced at the bottom, guess it has something to do with years in Roman times - https://en.wikipedia.org/wiki/Gregorian_calendar#Beginning_o... and that a year begins on September 11th in Ethiopia - http://en.wikipedia.org/wiki/Ethiopian_calendar)

One explanation might be that it depends on how you define "month" in this context. Is it a calendar month, or is it four weeks?

Or it's not a standard western calendar

I believe the missing context for that statement is timezones and daylight savings can cause it to be untrue.

It also happens in the japanese calendar, since the year changes when a new emperor ascends the throne and that might not happen on a first of a month

One take on it is better exemplified by saying something like "A day always begins and ends on the same date".

For the purposes of what the calendar says this it's ridiculous to assert that it's a falsehood. For other purposes, it might make perfect sense, for instance a "business day". When I was younger I worked at a bar. We opened at 11am and closed at 2am, and for accounting and legal reasons, the time period of 12am - 2am was the same day as when we opened. Technically we weren't even supposed to serve 21st birthday drinks after midnight, the lawyers said that violated the rules attached to the liquor license, but it wasn't ever enforced. From an accounting point of view - running reports, figuring out how much stock to order, how many people to staff, etc it makes a lot more sense to consider the business day than not.

We had a point of sale system that didn't have a business day notion, and frankly it did nothing but cause problems. Trying to figure out if our Friday and Saturday specials were working was a mess - a very large portion of sales at a bar catering to younger crowds happens after midnight. We were closed on sundays, but still (according to the PoS) realized a pile of income on Sundays. So to do our reports for the accountants we had to do a lot of manual handling of things. To the point where I had to figure out their DB storage and write a bit of code to pull things based on our business hours, just so I could get home before the sun came up when I did a busy weekend close.

Presumably there are similar notions of Month and Week that map to the same sort of reasoning, and there is such a thing as a fiscal year, in which the start and end of year may not be in the same calendar year.

A big reframing in my life was when I realized that timezones aren't a physical or mathematical construct: they're a legal construct.

This was driven home when Russia changed one of its timezones and we got bit by it because it turned out we had cached a build of tzdata years ago instead of building it from scratch every time we pushed out a new version (oops). The law went into effect and Russian users immediately started filing bugs.

Reposts are fine after a year or so (this is in the FAQ: https://news.ycombinator.com/newsfaq.html) but the most recent thread was much less than a year ago, so the current post counts as a dupe.

Falsehoods programmers believe about time - https://news.ycombinator.com/item?id=32548085 - Aug 2022 (204 comments)

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

Falsehoods Programmers Believe About Time (2012) - https://news.ycombinator.com/item?id=12675527 - Oct 2016 (154 comments)

Falsehoods programmers believe about time and time zones - https://news.ycombinator.com/item?id=11515125 - April 2016 (80 comments)

Falsehoods Programmers believe about Time - https://news.ycombinator.com/item?id=4128208 - June 2012 (213 comments)

Although the "minutes are always 60 seconds" falsehood probably won't be effected for some other reason, it's worth noting that Leap Seconds are being retired:

https://www.theguardian.com/world/2022/nov/18/do-not-adjust-...

The point is "a unit of time" is a human construct and we can, and do, whatever the hell we want with it.

I actually don’t like these lists.

All abstractions are falsehoods at some level, however, if you chase rabbit holes, you will never accomplish anything. Even the macro world is a falsehood/abstraction of the underlying quantum subatomic works (I think).

What matters is if your abstraction is good enough for what you goals are. For most of the lists I have seen, you can make valuable software that people will pay you for while still believing half the “lies”.

But it's very important to know what things you abstract over. At least as a rough outline.

For example, if you have the abstraction of all days being 24 hours which is fine. You should know though how far you may be off with that abstraction.

If your day suddenly is more than 4% longer or shorter, you might wonder about increased or decreased traffic for that day. You should know that there are cases where your abstraction is off and what the possible results of that are, even if you're not chasing that particular rabbit hole.

This is true, but again, within reason. I am 100% comfortable not knowing or understanding what design errors I have made that will cause my software to fail if used on a spaceship orbiting a black hole.

> If your day suddenly is more than 4% longer or shorter, you might wonder about increased or decreased traffic for that day.

I can confidently state that if there is a sudden change in the length of the day of 4% or greater, questions about traffic statistics tied to that on any website I am involved with be very low on my list of priorities.

I am not fond of the presentation either because of the negative framing, but it is still good information.

So that not taking account of 61 second minutes and 19 day months can be a deliberate decision and not something that catch you by surprise. As it is often the case, you can get away with believing half of the lies as long as it is the right half, but without context, there is no way to know which one is the right half.

This seemed relevant, given the lunar time discussions.

A bug in the implementation of some timekeeping function isn't a falsehood about time, it's a bug. A lot of these statements are true.

https://yourcalendricalfallacyis.com/

Partial-hour time zone offsets (like in Nepal or St. John’s Newfoundland) were a big learning moment for me back in the day.

"Time always goes forwards"

Reply on news.ycombinator.com