At NASA I wrote a set of Python scripts to help with planning and telemetry for a Mars mission. I had to convert a lot of time data points between UTC and a Mars timezone/clock (specific to the rover itself). There was an officially blessed tool written in Java that ran from the command line for time conversion. It was too slow to call out for each data point, so I figured it would be generally useful to port the conversion to Python.<p>First I dug into the Java source, which it turned out called out to a C library. I believe the C library linked out to a Fortran library. It was a lot more complicated than a simple scale and calendar - there were corrections for special and general relativity. Converting times actually required propagating orbits and estimating some non-closed-form quantities. In the end is was more work than it was worth, so we just did an approximation ("only" good to a few milliseconds - fine for our case).<p>So I guess item number 100 on this list should be "time is experienced the same way by all observers" and maybe 101 "simultaneity depends on the reference frame" :)
I don't know if these are all the same falsehoods, but—related:<p><i>Falsehoods programmers believe about time zones</i> - <a href="https://news.ycombinator.com/item?id=24870376" rel="nofollow">https://news.ycombinator.com/item?id=24870376</a> - Oct 2020 (16 comments)<p><i>Falsehoods programmers believe about time (2017)</i> - <a href="https://news.ycombinator.com/item?id=24453712" rel="nofollow">https://news.ycombinator.com/item?id=24453712</a> - Sept 2020 (8 comments)<p><i>Falsehoods programmers believe about Unix time</i> - <a href="https://news.ycombinator.com/item?id=19922062" rel="nofollow">https://news.ycombinator.com/item?id=19922062</a> - May 2019 (268 comments)<p><i>Falsehoods Programmers Believe About Time (2012)</i> - <a href="https://news.ycombinator.com/item?id=12675527" rel="nofollow">https://news.ycombinator.com/item?id=12675527</a> - Oct 2016 (154 comments)<p><i>Falsehoods programmers believe about time and time zones</i> - <a href="https://news.ycombinator.com/item?id=11515125" rel="nofollow">https://news.ycombinator.com/item?id=11515125</a> - April 2016 (80 comments)<p><i>Falsehoods Programmers believe about Time</i> - <a href="https://news.ycombinator.com/item?id=4128208" rel="nofollow">https://news.ycombinator.com/item?id=4128208</a> - June 2012 (213 comments)
Obviously nobody believes most of these falsehoods. Presumably the op means a lot of programmers create bugs that seem t imply programmers believe these falsehoods.<p>But this one jumped out at me: "Any 24-hour period will always begin and end in the same day". It would be a lot more plausible if "always" were replaced with "never". Add 24 hours to a time, and it will (almost) always be the next day.
When I start at a new company, it's always interesting to see how they handle dates and times. 1) Company A stores timestamps in a mysql database, no timezone, but implicitly on US pacific time. The system timezones are all on pacific. Many weird bugs around DST transitions. 2) Company B stores timestamps in a database as Unix timestamps (ints) Tons of code converting back and forth between ints. Code was a mess. 3) Company C stores them as postgres timestamp with timezone, which was always UTC in production. Code was reasonably sane.
Time would be much less of a problem if Terrestrial Time was used internally everywhere. That is: if TT (realized as TAI) were used as the fundamental definition of time, rather than UTC; and UTC were treated as just another timezone.<p>Then, there would be only three problems, which decompose nicely:<p>1. Trying to keep the system time accurate, and accounting for the possibility it isn't.
2. Having up-to-date time zone information
3. Converting TT to/from a date/time in some particular format in a particular timezone.<p>(1) is fundamentally unavoidable. (3) is complicated but well-defined. (2) should be handled by the system. All that's left is calculations on time values, which if they're in TT (i.e. actual time) are very well behaved.<p>Ultimately this is the fault of the standards bodies. POSIX defines time in terms of UTC. NTP tries to keep the system clock synced with UTC. Postgres "timestamp with timezone" stores UTC. Zone files state offsets in terms of UTC, and even worse, transition times are stated with reference to a timezone (see tzfile(5) and RFC 8536), which is completely insane.<p>This could change. Existing standards can't but new standards could be introduced to succeed the old ones and exist side-by-side. Maybe, instead of proposing changing UTC because they find leap seconds inconvenient, an organization like Facebook could actually do something useful and push for them.
The "opportunity for bugs" I didn't realize until I was over 10 years into my professional career:<p>10 AM<p>11 AM<p>12 PM <- AM/PM and calendar cycle is here.<p>01 PM <- n%12 cycle is here, an hour later.<p>02 PM<p>03 PM<p>I see large software systems for things like airlines and trains sometimes make this mistake, for instance a 1 hour trip on a ticket that says "11:30AM - 12:30AM" which is actually <i>negative</i> 11 hours.<p>I have a collection of photos somewhere of every time I've caught it. If I could change anything about time that probably nobody would care about, it would be to align those two cycles.<p>The fact that I catch it every couple months on widely deployed systems I interpret as the signal that basically nobody notices/cares about it as everyone knows a -11 hour train ride isn't how time works.
> GMT and UTC are the same timezone.<p>I got one for OP, too: UTC is not a timezone in the first place [1].<p>> 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.<p>The difference is subtle, but a standard is not subject to government whims while a timezone is.<p>1. <a href="https://www.timeanddate.com/time/gmt-utc-time.html#:~:text=UTC%20is%20not%20a%20time,UTC%20as%20a%20local%20time" rel="nofollow">https://www.timeanddate.com/time/gmt-utc-time.html#:~:text=U...</a>.
> The system clock will always be set to the correct local time.<p>I work on a <i>sometimes offline</i> educational product for children. Kids for some reason love to mess with their system clocks.<p>The hoops we've tried jumping through to get a reasonable time frame of events from iPads that were offline for any period of time is hilarious.<p>We gave up, and if the time of events is unreasonable, we just shift the entire set waiting to be synced so the first one is sync time. It's not perfect, it's not even really good, but it's gotten the least complaints.
> A week (or a month) always begins and ends in the same year<p>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?
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.
Is it just me, or does anybody else hate these "Falsehoods programmers believe about..." lists.<p>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.<p>What matters is how well the abstraction matches your use case, and where the leaks are.<p>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"),
Ugh.. I personally hate these lists. Absolutely no value added, nobody is going to remember these, they're gonna learn them the hard way and most importantly, if they don't work directly with the timekeeping infrastructure, probably never. And if they do work on the timekeeping infra, they likely know all of this.<p>Sure, you might run into some quirk at some point in your career but they will end up being just another weird war story.<p>I worked directly with NTP. The nitty-gritty details and the leap second smears and all of that, for an absolutely huge network and I find this list patronizing, smug and worthless. It's some sort of intellectual masturbation or just another instance of <a href="https://news.ycombinator.com/item?id=32335165" rel="nofollow">https://news.ycombinator.com/item?id=32335165</a>.
Python specific:<p>- `pytz.timezone(timezone_name)` will give you the current offset for that timezone
- well, it will at least be some consistent offset
- surely, every timezone has the same reference starting point?<p>What `pytz.timezone(name)` <i>actually</i> does is initialize a timezone object at the point in time of the first entry in the tz database for that zone. For example, New York had an offset of 4:56:02 prior to 1883 November 18, 12:03:58 [1]. That is the "starting point" for America/New_York and US/Eastern (which I think is an alias of New_York before a certain date). Which is why you get<p><pre><code> >>> pytz.timezone('America/New_York')
<DstTzInfo 'America/New_York' LMT-1 day, 19:04:00 STD>
</code></pre>
Ish. Not sure where those 2 seconds went. But that explains why you see that strange 19:04 (-3:56) offset. The real way to use it is<p><pre><code> >>> pytz.timezone('America/New_York').localize(your_specific_datetime)
</code></pre>
Timezones without a reference time are deceptive.<p>[1] <a href="https://en.wikipedia.org/wiki/Tz_database#Example_zone_and_rule_lines" rel="nofollow">https://en.wikipedia.org/wiki/Tz_database#Example_zone_and_r...</a>
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:<p><a href="https://harelang.org/blog/2022-04-17-chronology-in-hare/" rel="nofollow">https://harelang.org/blog/2022-04-17-chronology-in-hare/</a><p>To stress test our implementation (and to flex on other languages), we're implementing Martian time in it as well.<p><a href="https://harelang.org/blog/2022-08-01-martian-time-in-hare/" rel="nofollow">https://harelang.org/blog/2022-08-01-martian-time-in-hare/</a><p><pre><code> // 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
</code></pre>
My current litmus test goal for it is to get strftime to print out 23:23:60.
Falsehoods programmers believe about falsehoods:<p>* Something is a falsehood because it's not true in every context<p>* Something is a falsehood because it's not true in many contexts<p>* Something is a falsehood because it's not true in any context but the one the programmer cares about<p>(and the correct context is often “whatever deals with the company's bullshit problem with the least effort”)
In the U.S. falling back to standard time from daylight saving time is rough. Those days have 25 hours - and the interval from 1:00 - 2:00 repeats (you reach 2:00 and fallback to 1:00 and repeat the interval). Makes power scheduling difficult - <i>which</i> 1:00 - 2:00 interval are you talking about?<p>Also, the offsets between the timezones change. Eastern Daylight Time falls back from 2:00 to 1:00 Eastern Standard Time, which coincides with 1:00 for Central Daylight Time. So Eastern Time and Central Time are the same for one hour interval. Of course in the Spring you have the opposite problem - Central Time will be 2 hours behind Eastern Time for a one hour interval. So much for your interval time calculations! Also, the U.S. has changed the transition dates for the time change.<p>I'm so glad to be working on a system where I no longer have to worry about this crap!
Of about 96 entries, I count 27 instances of "Always" and 12 instances of"Never"<p>Reminds me of the old SAT hints:
Beware of statements and questions with "always", "never", "must", and "cannot".
We should just define a year to be 360 days long and made up of 12 30 day months.<p>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."<p>Or we could define a 5.5+-.5 day holiday between the beginning and end of a given year. Those days will be declared to not belong to any year. We will turn off all our computers for those days, and pretend they didn't happen. If you are born within them, you get a special hat or something.
"Months have either 28, 29, 30, or 31 days."<p>Ok, Im intrigued, are there months that don't? I assume it must be a country specific thing?
<i>The system clock will never be set to a time that is in the distant past or the far future.</i><p>Right but if that's the case, what exactly can you do about it?
Oh I have a great one:<p>> days don't overlap<p>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.
The proposed moral of this story, and those like it, is to avoid re-implementing general-purpose libraries.<p>Yes, good. But not all applications need a “platonic ideal” understanding of time. Often when you type just the code you need, the system performs excellently, and the code is minimal.
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.
Also one thing I have noticed is that the system clocks are actually pretty bad. Or I would expect them to be much better. This can be easily noticed when you don't have active time sync on machine. Drift is multiple seconds in not that many days.
I've worked with calendar applications and todo managers, alarms, recurring events and all that. Our timekeeping mechanics are incredibly complex.<p>24hs before 15:00 is USUALLY 15:00. But in some timezones, it can be (about once a year): 14:00, 16:00 or 14:59:59.<p>It's currently Monday 11:02 here, but it's likely still Sunday in some parts of the world (or is it already Tuesday somewhere? Not sure which is right). So, right now "today" have no single meaning; it depends on where you are.<p>Oh, and does your online meeting repeat at 14hs CET every Monday? Then for people in Argentina it will be at 9hs for six months a year, and at 10hs for another six months (due to CET having DST, but not Argentina).
I've just learned to do time conversions by converting from the target timezone to UST, then from UST, to the recipient timezone.<p>Hasn't failed me yet.<p>Here's why: <a href="https://www.nist.gov/sites/default/files/images/2019/12/23/worldzones.gif" rel="nofollow">https://www.nist.gov/sites/default/files/images/2019/12/23/w...</a><p>This looks useful. I haven't checked for full accuracy: <a href="https://www.timeanddate.com/time/map/" rel="nofollow">https://www.timeanddate.com/time/map/</a>
>Leap years occur every 4 years.<p>Isn't leap year calculation one of the very first things you do in most programming tutorials/schools? I know that a lot of people don't know this, but most programmers should, r-r-r-right?
Unimportant sidenote: I don't like the naming of these "falsehoods programmers believe about X" lists. Surely programmers are more likely to be conscious of these not being true than non-programmers.
I always enjoyed an entertaining talk by Peter Hall on this subject: <a href="https://youtu.be/bJmx0tcVubY?t=3224" rel="nofollow">https://youtu.be/bJmx0tcVubY?t=3224</a>
> The day of the month always advances contiguously from N to either N+1 or 1, with no discontinuities.<p>I would've presumed this one - for the Gregorian calendar, at least. What are some counterexamples?
> Britain uses GMT.<p>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.
Does anyone actually believe this?<p>Even the most inexperienced developers I’ve worked with are well aware that time, and timezones in particular, are really difficult.<p>I’ve yet to meet anyone that has suggested using anything other than a battle-hardened standard library for time.
Missed one: <a href="https://en.wikipedia.org/wiki/Leap_second" rel="nofollow">https://en.wikipedia.org/wiki/Leap_second</a>
Yes, there are NOT 60 seconds in a minute...
Just wait till you hear about leap seconds.<p>At my previous job matching datapoints on timestamp was crucial, so we did a lot of fun things with time. Leap seconds cost us 3 months of testing.
Similar thing for Names:<p>Falsehoods Programmers Believe About Names
<a href="https://news.ycombinator.com/item?id=1438472" rel="nofollow">https://news.ycombinator.com/item?id=1438472</a>