16 ms·

Falsehoods programmers believe about time

178 points by rrampage 4y ago

mayoi 4y ago
Missed one: https://en.wikipedia.org/wiki/Leap_second https://en.wikipedia.org/wiki/Leap_second Yes, there are NOT 60 seconds in a minute...
yreg 4y ago
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.
- vaylian 4y ago
  I still encounter forms on the web or input fields in software that prevent me from entering truthful information or that require me to input information that doesn't exist. There are definitely still programmers out there that make assumptions that don't hold in all cases.
  - deleted 4y ago
    [deleted]
- edent 4y ago
  It isn't "falsehoods all programmers believe..." it's "falsehoods that [some|lots|many|inexperienced] programmers believe..." Unless you work all day on time-related software, you'll probably never encounter most of these quirks. Humans don't write in BNF. We expect, rightly or wrongly, for other humans to use Postel's law to interpret what we mean.
  - jstanley 4y ago
    But the point is that programmers are less likely to believe these things than ordinary people are.
    - xboxnolifes 4y ago
      By putting the intended audience in the title, you grab their attention more.
      - yreg 4y ago
        It's clickbait. Computerphile managed a much better title[1]: The Problem with Time & Timezones A "(for programmers)" could be appended if needed. [1] https://www.youtube.com/watch?v=-5wpm-gesOY https://www.youtube.com/watch?v=-5wpm-gesOY
        xboxnolifes 4y ago
        Its not click bait, the contents are what the title claim to be.
    - edflsafoiewq 4y ago
      The point is these are falsehoods whose belief can affect a programmer's work when they get embedded into the systems they create. The point is to correct yourself, not tu quoque your brother.
    - anthony_d 4y ago
      But they’re more likely to be impacted.
- bryanrasmussen 4y ago
  well basically it's shorthand for "things that do not apply to every locale for X of instance of Y, that programmers have decided to implement as if they do apply to every locale or instance either through not realizing they do not apply or that the non-applicability in some situations are such bizarre outliers in relation to the rest of the world that it has been decided to be an acceptable bug that they will not fix" but that's not very pithy. But of course what happens is the outliers have to deal with these systems that treat them as bad data possessing impossible properties and then the curse and say hey these stupid programmers don't realize that the world is not just like X1 or Y1, but that us rare instances of X2 and Y2 also exist! And then an expert with sufficient knowledge about all the outliers compiles a list entitled Falsehoods Programmers believe about {X}.
- WhyNotHugo 4y ago
  Programmer that have worked with timekeeping: yes. Average programmer who hasn't done anything datetime-specific: unlikely.
- mayoi 4y ago
  No, they are not. Beyond leap years and leap seconds, I know absolutely nothing about time, how to handle all the "daylight savings" and other kind of bullshit. And I actually do not care, at all. Luckily for me, people who do care and know these things have made libraries that can handle it all while expecting only minimal knowledge from me, such as being aware that time zones exist at all.
  - yreg 4y ago
    The reason why you use those libraries is that you know time is difficult and you need to be cautious. You don not blindly believe those statements about time. If pressed to answer whether they are right or wrong you would say that you are not sure.
    - mayoi 4y ago
      And I'm not sure how this contradicts what I wrote.
      - yreg 4y ago
        Arguing about this is not productive, so sorry in advance, but just to explain myself: me: programmers are less likely to believe this stuff than non-programmers you: no, they are not me: programmers are conscious that time is more complex than it seems to be, therefore they avoid holding simple beliefs regarding it
bennyp101 4y ago
"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?
- k4rli 4y ago
  Maybe they're developing software to be used on Mars? 687 day years mentioned in Gist comments.
- Schroedingersat 4y ago
  Most countries had at least one month that differed some time from 1580ish to 1800ish when they switched calenders Don't know about more recent examples
  - Ekaros 4y ago
    https://en.wikipedia.org/wiki/List_of_adoption_dates_of_the_Gregorian_calendar_by_country https://en.wikipedia.org/wiki/List_of_adoption_dates_of_the_... Actually looking at that tells me it is a mess... Like Belarus and Lithuania changing back to Julian calendar in 1800... And then again to Gregorian in 1918.
- WhyNotHugo 4y ago
  September 1752
  - NeoTar 4y ago
    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_the_Gregorian_calendar_by_country https://en.m.wikipedia.org/wiki/List_of_adoption_dates_of_th...
- detaro 4y ago
  I'd expect in a lunar calendar system? (where 12 lunar months are to short to fill a year, and I think some of them fix this by inserting an extra half-month) But I wish this list came with examples, and if it really means a different calendar system it's IMHO not as interesting, because it's IMHO fairly obvious that different calendar systems follow different rules. Or maybe during the switch to Gregorian calendar? That you'd at least encounter with dates for things long ago - although that transition is very "here be dragons" and very local.
shafyy 4y ago
> There are always 24 hours in a day. Is this referring to leap seconds or what do the mean?
- jstanley 4y ago
  When the timezone changes for daylight savings time, you either lose or gain 1 hour in that day (or whatever your local equivalent is).
  - shafyy 4y ago
    Makes sense, thanks!
  - controversial97 4y ago
    Except for Lord Howe Island in New South Wales, Australia, where local time changes by 30 minutes.
- _dain_ 4y ago
  Daylight savings, or the device is on a plane and travels through timezones.
  - defrost 4y ago
    Or, back when I was doing airborne geophysical surveying across the Fijian archipelago the plane would flit from -179 to +179 longitude a few times every hour with a potential change of a full day if being naive about time zones. Data aquisition instrumentation needs to use a lapsed epoch (to avoid UTC leap seconds) with a calibration at start and end of projects to adjust for drift, etc.
- WhyNotHugo 4y ago
  23hs or 25hs during DST transitions are the most obvious exception (twice a year in many many countries).
  - MerelyMortal 4y ago
WhyNotHugo 4y ago
I've worked with calendar applications and todo managers, alarms, recurring events and all that. Our timekeeping mechanics are incredibly complex. 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. 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. 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).
- Ekaros 4y ago
  14h CET is 14h CET each and every time. It is just that we automatically reschedule it to 14h CEST when summertime is in use. Also it is in use for 7 months not 6 months...
cgrealy 4y ago
Does anyone actually believe this? Even the most inexperienced developers I’ve worked with are well aware that time, and timezones in particular, are really difficult. I’ve yet to meet anyone that has suggested using anything other than a battle-hardened standard library for time.
- WhyNotHugo 4y ago
  > Does anyone actually believe this? Does any programmer believe ALL these falsehoods? Not very likely. Do most programmers believe AT LEAST ONE of these falsehoods? Likely. > I’ve yet to meet anyone that has suggested using anything other than a battle-hardened standard library for time. Many stdlibs still don't account for the most edge of corner cases -- or make it very easy to screw up anyway.
- BurningPenguin 4y ago
  I once worked for a company, where the gps platform had multiple time related problems. This list pretty much sums it all up.
- bee_rider 4y ago
  I bet you could get me to give the wrong answer to most of these questions if you worded it cleverly in informal conversation, but the answer to anything time and date related in a technical setting is "Ugh, we'll have to look up the stupid edge cases here," right?
  - cgrealy 4y ago
    Exactly. And you also need to understand your timing requirements. If all you care about is recording a date on an invoice, you really don’t need to worry about leap seconds or smearing or whatever.
- yccs27 4y ago
  Even if you use a library, it's easy to bake in an "obvious" assumption into your program. Such as storing location + date + time, because that should be unambiguous, right? Or confusing "same time tomorrow" with now + 24h. Are you even sure which one you need?
wodenokoto 4y ago
I think the list would be much more interesting and educational if it provided examples.
- piersj225 4y ago
  Jon Skeet has put together a talk on Dates and time zones talking about some examples https://www.youtube.com/watch?v=DhYUcxRWWQI https://www.youtube.com/watch?v=DhYUcxRWWQI
SwiftyBug 4y ago
> 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?
- grardb 4y ago
  Here you go: https://youtu.be/-5wpm-gesOY?t=368 https://youtu.be/-5wpm-gesOY?t=368 I'd highly recommend watching the whole video, by the way. It's really good.
  - idiocrat 4y ago
    Work in Finance. My year starts on April 1st. I do not want my year to start on January 1st, else I will need to work through all holidays for year-end closing.
- amarant 4y ago
  I don't think they mean what you think they mean. I think they mean that if someone says "remind me in a month" On December 3rd, the reminder would be next year. I've never met a developer who believed that, but I've met plenty who would forget about the edge-case and write a buggy time-library. As is the case for most of these.
- slaymaker1907 4y ago
  There is a concept of "week year" in Java so a given month could simultaneously exist in two (week) years.
- saalweachter 4y ago
  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.
dailykoder 4y ago
>Leap years occur every 4 years. 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?
- atoav 4y ago
  If you handle dates and times yourself on that level, prepare to be in a world of pain. Handling time and dates correctly has a similar difficulty to writing your own cryptographic primitives: If you don't know exactly what you are doing you will shoot yourself (and potentially countless others) into the foot at one in point or another.
  - rocqua 4y ago
    See also the problems in the Excel datetime calculations that are now unfixable because a fix would break many existing problems. e.g. https://en.wikipedia.org/wiki/Leap_year_problem https://en.wikipedia.org/wiki/Leap_year_problem
  - wruza 4y ago
    Tbh, half of my life I handled them on a financial platform which couldn’t care less of the subj list or standards. It has just ‘wall date’ like yyyy-mm-dd and ‘wall time’ strictly in 00:00:00-23:59:59 range, without a timezone. Two separate types. Never encountered of even heard of any time-related bug there. I find this simplified date/time very useful, unless you have to manage “continuous and/or real” time somehow. 99% of applications are okay with it, because they’re facing users with exactly the same mental model. Also, albeit not correct scientifically, it reflects many developers’ mental model as well. This is much better than a model that just doesn’t match, which is a world of pain. Someone adds 86400 but it’s the same day, good luck debugging it. I don’t think this is a cryptographic-level issue.
    - bee_rider 4y ago
      My uninformed guess would be that a financial platform mostly just wants a monotonically increasing clock with which to order transactions. So this would I guess avoid quite a bit of the annoying date related stuff. (?) Anyway if you queried something to get the current date-time and clock-time, you could be farming out the annoying edge cases to some arbitrarily complicated library, right? Which is the right way to do things.
Ekaros 4y ago
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.
mnw21cam 4y ago
> 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.
- r00fus 4y ago
  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 https://en.wikipedia.org/wiki/British_Summer_Time
  - NateEag 4y ago
    I have never had an opportunity to deploy this tool, but here's a program for generating a TZ shapefile from OpenStreetMap data: https://github.com/evansiroky/timezone-boundary-builder https://github.com/evansiroky/timezone-boundary-builder In principle a calendar program could use its output to perform GIS lookups of locations then use the tzinfo DB to get the correct timezone at the given location and specified time.
taylodl 4y ago
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 - which 1:00 - 2:00 interval are you talking about? 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. I'm so glad to be working on a system where I no longer have to worry about this crap!
- UncleEntity 4y ago
  During the last “fall back” event I experienced the 1 o’clock hour three times since I randomly happened to cross a time zone at exactly 2:00am…or maybe 1:00am? The worst part was I had an appointment at 02:00, somewhere where they won’t let you in if you show up too early, in the other time zone and hadn’t had to deal with daylight savings time for a good long while having lived in Arizona where they don’t deal with such silliness. Trying to figure out what time to leave to time my arrival was very difficult.
  - ufmace 4y ago
    > having lived in Arizona where they don’t deal with such silliness Oh god, I'm simultaneously delighted at the idea of not having to deal with DST and terrified of writing software that might have to keep track of whether or not the user was in Arizona during a DST transition.
    - UncleEntity 4y ago
      Arizona just stays on MST year long making it easy unless you have to figure out what time everyone else is on. And for even more fun the Navajo Nation does do time zone changes.
    - 4y ago
dang 4y ago
I don't know if these are all the same falsehoods, but—related: Falsehoods programmers believe about time zones - https://news.ycombinator.com/item?id=24870376 https://news.ycombinator.com/item?id=24870376 - Oct 2020 (16 comments) Falsehoods programmers believe about time (2017) - https://news.ycombinator.com/item?id=24453712 https://news.ycombinator.com/item?id=24453712 - Sept 2020 (8 comments) Falsehoods programmers believe about Unix time - https://news.ycombinator.com/item?id=19922062 https://news.ycombinator.com/item?id=19922062 - May 2019 (268 comments) Falsehoods Programmers Believe About Time (2012) - https://news.ycombinator.com/item?id=12675527 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 https://news.ycombinator.com/item?id=11515125 - April 2016 (80 comments) Falsehoods Programmers believe about Time - https://news.ycombinator.com/item?id=4128208 https://news.ycombinator.com/item?id=4128208 - June 2012 (213 comments)
- pigbearpig 4y ago
  Should the link be updated to the actual source? This gist appears to just be a copy of https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time https://infiniteundo.com/post/25326999628/falsehoods-program... and https://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time https://infiniteundo.com/post/25509354022/more-falsehoods-pr... https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca#sources https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b...
  - dang 4y ago
    Sure—changed from https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b... now. Thanks! (For some reason people think we know these things)
    - cwillu 4y ago
      Falsehoods hn'ers believe about dang…
bee_rider 4y ago
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 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.
- Bilal_io 4y ago
  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.
  - vlunkr 4y ago
    You're going to take issue with that instead of Druid part?
    - teddyh 4y ago
      I hereby announce my campaign for the role of Time Druid.
      - flir 4y ago
        Your symbols of office shall be a blinking 12:00 and the date 01-01-1970. Wait. In fact, if you weren't born on 01-01-1970, you can't be Time Druid. Sorry.
        alexfoo 4y ago
ChrisMarshallNY 4y ago
I've just learned to do time conversions by converting from the target timezone to UST, then from UST, to the recipient timezone. Hasn't failed me yet. Here's why: https://www.nist.gov/sites/default/files/images/2019/12/23/worldzones.gif https://www.nist.gov/sites/default/files/images/2019/12/23/w... This looks useful. I haven't checked for full accuracy: https://www.timeanddate.com/time/map/ https://www.timeanddate.com/time/map/
- deleted 4y ago
  [deleted]
RcouF1uZ4gsC 4y ago
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"),
- madamelic 4y ago
  Here's my tl;dr for "falsehoods programmers believe about [x]" so you never have to read another: Don't make assumptions. You aren't smart. Keep it simple and don't get clever.
- elcamino44 4y ago
  I think I understand why you feel this way, but I personally find them to be a helpful format. For example, last time I had to figure out how to store addresses in a database I made a point to check out the falsehoods programmers believe about addresses document (as well as other sources).
- iainmerrick 4y ago
  I can’t stand them. It’s a smug, click-baity and passive-aggressive format, typically without any actual examples.
ddevault 4y ago
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/ 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/ 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.
- macintux 4y ago
  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”.
  - ddevault 4y ago
    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 https://docs.harelang.org/datetime#builder
    - wruza 4y ago
      Too bad that most stdlibs outscope it to third parties. Wildcard periods are essential for some applications (even as simple as a periodic reminder) and also are hard to do correctly. I’d say a period is actually more important than a date, because we mostly work with periods, and our “datetimes” are just integer coordinates of pixels of time, so to say.
LAC-Tech 4y ago
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?
- madamelic 4y ago
  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")
  - LAC-Tech 4y ago
    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?
    - IncRnd 4y ago
      In that case, the best you can hope for is to centralize time on the server. The IoT devices can keep local differential time or contact the server (or a log server or somewhere else) at the time of the event. It's kind of messy, since you are asking to trust a client's data, which is untrustworthy.
  - rcoveson 4y ago
    > 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.
  - askvictor 4y ago
    Have had plenty of problems with WPA-Enterprise auth refusing to join a wifi network on account of a wildly wrong computer time. Which in turn means that the computer can't get a correct time on account of not being able to ask an NTP server.
thenightcrawler 4y ago
I'd like to hear about how to write software orbiting a black hole?
- marcosdumay 4y ago
  As long as you don't change orbits, you should be fine.
  - SilasX 4y ago
    "Falsehoods programmers believe about black hole orbits..."
- mhh__ 4y ago
  Very carefully indeed
- NovemberWhiskey 4y ago
  I mean, you're sort of there already? The galactic barycenter is a supermassive black hole called Sagittarius A*.
behnamoh 4y ago
Similar thing for Names: Falsehoods Programmers Believe About Names https://news.ycombinator.com/item?id=1438472 https://news.ycombinator.com/item?id=1438472
- pvg 4y ago
  The Unreasonable Effectiveness of Falsehoods Programmers Believe Considered Harmful https://news.ycombinator.com/item?id=3735928559 https://news.ycombinator.com/item?id=3735928559
  - zdwolfe 4y ago
    Is this link correct? I get a 404.
    - pvg 4y ago
      So harmful they had to censor it.
  - anon_123g987 4y ago
    Awesome Falsehood - A curated list of falsehoods programmers believe in https://github.com/kdeldycke/awesome-falsehood https://github.com/kdeldycke/awesome-falsehood
andyferris 4y ago
I always enjoyed an entertaining talk by Peter Hall on this subject: https://youtu.be/bJmx0tcVubY?t=3224 https://youtu.be/bJmx0tcVubY?t=3224
uniqueuid 4y ago
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.
takinola 4y ago
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.
- at-fates-hands 4y ago
  I personally have not had much experience with it. Would love to hear some horror stories you've encountered. It might help me keep an eye out for it.
  - jamesfinlayson 4y ago
    Trying to deal with conversion between time zones or to/from daylight saving can have gotchas which libraries will deal with for you.
- bentcorner 4y ago
  I agree. I'd wager most programmers don't need to actually worry about calendars, but most occasionally need to worry about time. Just use a library and read the docs for what to expect to happen when you do something like getCurrentTime. What is the resolution, does it monotonically increase, etc. If you actually need to worry about calendars and user input, you have my sympathy.
  - mjevans 4y ago
    Handing those cases correctly might very well be a Turing test...
gillesjacobs 4y ago
> 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=UTC%20is%20not%20a%20time,UTC%20as%20a%20local%20time https://www.timeanddate.com/time/gmt-utc-time.html#:~:text=U....
- naniwaduni 4y ago
  Still subject to IERS whims, though.
  - gillesjacobs 4y ago
    Sure but governments can and do change timezones more regularly than programmers keep up [1]. In 2014, Egypt's new government changed their timezone with only a week notice. Updating standards almost never happens, unless with a name/identifier change. The whole point of standardized measures is their immutability. [1] https://www.timeanddate.com/news/time/ https://www.timeanddate.com/news/time/ [2] https://english.ahram.org.eg/News/100735.aspx https://english.ahram.org.eg/News/100735.aspx
- deleted 4y ago
  [deleted]
suzzer99 4y ago
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.
- ccooffee 4y ago
  Many years ago, a user filed a bug report that the timezone information we used for historical places in Indiana was incorrect. I don't remember exactly what the user was doing, but I think it had something to do with train schedules or something. I did not fix that bug. (But I did learn that the 'TZ' database has this information, though I think 'America/Indiana/*' had been pruned out of the copy our JVM was using.)
  - IncRnd 4y ago
    Some of Indiana is on the Central Timezone and some is on the Eastern Timezone. This is definitely an issue!
kristopolous 4y ago
The "opportunity for bugs" I didn't realize until I was over 10 years into my professional career: 10 AM 11 AM 12 PM <- AM/PM and calendar cycle is here. 01 PM <- n%12 cycle is here, an hour later. 02 PM 03 PM 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 negative 11 hours. 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. 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.
- not2b 4y ago
  I missed a plane flight once because an admin for the company I was working with booked a midnight flight accidentally and I thought it was at noon (I think she thought so as well). I think it was in the 90s sometime.
  - UncleEntity 4y ago
    Not very long ago I showed up to an appointment at 7:00 am and was told it was really at 19:00 — and our computer system uses 24 hour time so obviously someone just screwed up the conversion. Midnight appointment are interesting since the system doesn’t have “no appointment time” so they use 00:00 and 00:01 for a real midnight appointment and if you’re really, really tired…
- gsich 4y ago
  am/pm users have lost their sanity.
  - BonoboIO 4y ago
    I m surprised it’s not 7 inch past 12
- BurningFrog 4y ago
leecommamichael 4y ago
The proposed moral of this story, and those like it, is to avoid re-implementing general-purpose libraries. 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.
- DiggyJohnson 4y ago
  I think your comment makes sense for pretty much any domain other than timekeeping though, and to claim otherwise is to take nothing away from TFA.
kortex 4y ago
Python specific: - `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? What `pytz.timezone(name)` actually 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 >>> pytz.timezone('America/New_York') <DstTzInfo 'America/New_York' LMT-1 day, 19:04:00 STD> 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 >>> pytz.timezone('America/New_York').localize(your_specific_datetime) Timezones without a reference time are deceptive. [1] https://en.wikipedia.org/wiki/Tz_database#Example_zone_and_rule_lines https://en.wikipedia.org/wiki/Tz_database#Example_zone_and_r...
- hermitdev 4y ago
  Can probably add another falsehood: that timezone information (in particular DST & UTC offsets) will never change. In reality, timezones are very much political and can change at any time with sometimes very little notice. Last major change US folks may remember occurred around 2007, when daylight saving time was expanded by 6 weeks. I know of clocks that are still wrong from that change. At a previous job, I spent over a year working on a library for timezones built on top of Boost. The handling of historical timezones was a particular pain in the ass.
icedchai 4y ago
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.
- fingerlocks 4y ago
  > Tons of code converting back and forth between ints. Code was a mess. Never experienced this myself, it’s trivial in all the languages I can think of. Sometimes you have multiply or divide by 1000 if JavaScript is involved. I always prefer Unix epoch time. What was the language and stack causing the mess so I know to avoid it?
  - icedchai 4y ago
    The code was a mess for other reasons beyond the int/timestamp conversions. In some places it was stored as milliseconds, other places seconds. It was python 2 if it matters.
donatj 4y ago
> The system clock will always be set to the correct local time. I work on a sometimes offline educational product for children. Kids for some reason love to mess with their system clocks. 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. 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.
- Retr0id 4y ago
  > Kids for some reason love to mess with their system clocks. There are plenty of mobile games that will time-gate in-game rewards (e.g. wait x hours to unlock y). Often, messing with the system clock skips these delays. You're welcome.
- IncRnd 4y ago
  > Kids for some reason love to mess with their system clocks. They are cheating at games!
- dekleinewolf 4y ago
  My dad has some insomnia problems and used to play a lot of Candy Crush. His iPad was like 2 centuries ahead because moving the system time would give him extra lives. He couldn't practically move it back because then he'd have to wait another 2 centuries to get lives again. So his iPad was 2 centuries ahead until he completed Candy Crush.
CliffStoll 4y ago
Of about 96 entries, I count 27 instances of "Always" and 12 instances of"Never" Reminds me of the old SAT hints: Beware of statements and questions with "always", "never", "must", and "cannot".
decebalus1 4y ago
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. Sure, you might run into some quirk at some point in your career but they will end up being just another weird war story. 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 https://news.ycombinator.com/item?id=32335165 https://news.ycombinator.com/item?id=32335165.
gweinberg 4y ago
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. 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.
- pjscott 4y ago
  Agreed on all counts. The “falsehoods programmers believe about X” articles are cautionary lists of edge cases to think about, with an unfortunately aggressive naming scheme.
  - ryandrake 4y ago
    They should really call these lists "Incorrect assumptions programmers make about X" or: "Test cases programmers should test their software against"
    - mgkimsal 4y ago
      Or “boundaries users have to stay within”. I’m aware of a lot of edge cases. When you start building with those in mind, it adds complications. Extra steps or more UI or whatever, to ensure the “right” thing happens, assumptions are obvious, etc. More often than not I’m pushed back in with “that doesn’t happen” or “don’t spend time on that”. “We’re never open past 9, don’t worry about a day” but then they acquire a system in a different time zone and … boom. Things are broken.
  - fomine3 4y ago
    Falsehoods programmers Considered harmful
- jerf 4y ago
  There are the things you say you believe, and there are the things your actions show you believe. This extends well past simple matters of time in computers. Some of my favorite things lie in the fractal fringe categories between those, such as, "the things you didn't realize you believed (by your actions) until someone pointed them out to you" and "the things you didn't realize you should believe (in any sense) until someone pointed them out to you, at which point they seemed blindingly obvious and you can't believe you missed it".
wyldfire 4y ago
> The day of the month always advances contiguously from N to either N+1 or 1, with no discontinuities. I would've presumed this one - for the Gregorian calendar, at least. What are some counterexamples?
- bobbylarrybobby 4y ago
  Well, if by day advancing you (they) mean adding 24 hours to a given datetime, then a 23 hour day would cause the date to advance by two.
- NateEag 4y ago
  See e.g. the British transition from Julian to Gregorian calendars, in which eleven days of September 1752 were not observed in England: https://en.m.wikipedia.org/wiki/Calendar_(New_Style)_Act_1750 https://en.m.wikipedia.org/wiki/Calendar_(New_Style)_Act_175... IIRC, that event is the reason SQLServer's datetime type is only good back to 1753, and thus why you should use datetime2 for dealing with older historical dates: https://database.guide/datetime-vs-datetime2-in-sql-server-whats-the-difference/ https://database.guide/datetime-vs-datetime2-in-sql-server-w...
joshthecynic 4y ago
dkbrk 4y ago
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. Then, there would be only three problems, which decompose nicely: 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. (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. 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. 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.
- Tepix 4y ago
  If the system time isn't accurate most of the problems would still apply.
- deleted 4y ago
  [deleted]
cwillu 4y ago
Falsehoods programmers believe about falsehoods: * Something is a falsehood because it's not true in every context * Something is a falsehood because it's not true in many contexts * Something is a falsehood because it's not true in any context but the one the programmer cares about (and the correct context is often “whatever deals with the company's bullshit problem with the least effort”)
rzimmerman 4y ago
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. 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). 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" :)
- hoseja 4y ago
  One glorious day we'll switch to outside-of-gravity-well coordinated reference time frame.
dekleinewolf 4y ago
Just wait till you hear about leap seconds. 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.
- seabea 4y ago
  Meta (among others) want to change that. https://engineering.fb.com/2022/07/25/production-engineering/its-time-to-leave-the-leap-second-in-the-past/ https://engineering.fb.com/2022/07/25/production-engineering...

178 points by rrampage 4y ago

Missed one: https://en.wikipedia.org/wiki/Leap_second https://en.wikipedia.org/wiki/Leap_second Yes, there are NOT 60 seconds in a minute...

yreg 4y ago

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.

vaylian 4y ago
I still encounter forms on the web or input fields in software that prevent me from entering truthful information or that require me to input information that doesn't exist. There are definitely still programmers out there that make assumptions that don't hold in all cases.
- deleted 4y ago
  [deleted]
edent 4y ago
It isn't "falsehoods all programmers believe..." it's "falsehoods that [some|lots|many|inexperienced] programmers believe..." Unless you work all day on time-related software, you'll probably never encounter most of these quirks. Humans don't write in BNF. We expect, rightly or wrongly, for other humans to use Postel's law to interpret what we mean.
- jstanley 4y ago
  But the point is that programmers are less likely to believe these things than ordinary people are.
  - xboxnolifes 4y ago
    By putting the intended audience in the title, you grab their attention more.
    - yreg 4y ago
      It's clickbait. Computerphile managed a much better title[1]: The Problem with Time & Timezones A "(for programmers)" could be appended if needed. [1] https://www.youtube.com/watch?v=-5wpm-gesOY https://www.youtube.com/watch?v=-5wpm-gesOY
      - xboxnolifes 4y ago
        Its not click bait, the contents are what the title claim to be.
  - edflsafoiewq 4y ago
    The point is these are falsehoods whose belief can affect a programmer's work when they get embedded into the systems they create. The point is to correct yourself, not tu quoque your brother.
  - anthony_d 4y ago
    But they’re more likely to be impacted.
bryanrasmussen 4y ago
well basically it's shorthand for "things that do not apply to every locale for X of instance of Y, that programmers have decided to implement as if they do apply to every locale or instance either through not realizing they do not apply or that the non-applicability in some situations are such bizarre outliers in relation to the rest of the world that it has been decided to be an acceptable bug that they will not fix" but that's not very pithy. But of course what happens is the outliers have to deal with these systems that treat them as bad data possessing impossible properties and then the curse and say hey these stupid programmers don't realize that the world is not just like X1 or Y1, but that us rare instances of X2 and Y2 also exist! And then an expert with sufficient knowledge about all the outliers compiles a list entitled Falsehoods Programmers believe about {X}.
WhyNotHugo 4y ago
Programmer that have worked with timekeeping: yes. Average programmer who hasn't done anything datetime-specific: unlikely.
mayoi 4y ago
No, they are not. Beyond leap years and leap seconds, I know absolutely nothing about time, how to handle all the "daylight savings" and other kind of bullshit. And I actually do not care, at all. Luckily for me, people who do care and know these things have made libraries that can handle it all while expecting only minimal knowledge from me, such as being aware that time zones exist at all.
- yreg 4y ago
  The reason why you use those libraries is that you know time is difficult and you need to be cautious. You don not blindly believe those statements about time. If pressed to answer whether they are right or wrong you would say that you are not sure.
  - mayoi 4y ago
    And I'm not sure how this contradicts what I wrote.
    - yreg 4y ago
      Arguing about this is not productive, so sorry in advance, but just to explain myself: me: programmers are less likely to believe this stuff than non-programmers you: no, they are not me: programmers are conscious that time is more complex than it seems to be, therefore they avoid holding simple beliefs regarding it

bennyp101 4y ago

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

k4rli 4y ago
Maybe they're developing software to be used on Mars? 687 day years mentioned in Gist comments.
Schroedingersat 4y ago
Most countries had at least one month that differed some time from 1580ish to 1800ish when they switched calenders Don't know about more recent examples
- Ekaros 4y ago
  https://en.wikipedia.org/wiki/List_of_adoption_dates_of_the_Gregorian_calendar_by_country https://en.wikipedia.org/wiki/List_of_adoption_dates_of_the_... Actually looking at that tells me it is a mess... Like Belarus and Lithuania changing back to Julian calendar in 1800... And then again to Gregorian in 1918.
WhyNotHugo 4y ago
September 1752
- NeoTar 4y ago
  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_the_Gregorian_calendar_by_country https://en.m.wikipedia.org/wiki/List_of_adoption_dates_of_th...
detaro 4y ago
I'd expect in a lunar calendar system? (where 12 lunar months are to short to fill a year, and I think some of them fix this by inserting an extra half-month) But I wish this list came with examples, and if it really means a different calendar system it's IMHO not as interesting, because it's IMHO fairly obvious that different calendar systems follow different rules. Or maybe during the switch to Gregorian calendar? That you'd at least encounter with dates for things long ago - although that transition is very "here be dragons" and very local.

shafyy 4y ago

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

jstanley 4y ago
When the timezone changes for daylight savings time, you either lose or gain 1 hour in that day (or whatever your local equivalent is).
- shafyy 4y ago
  Makes sense, thanks!
- controversial97 4y ago
  Except for Lord Howe Island in New South Wales, Australia, where local time changes by 30 minutes.
_dain_ 4y ago
Daylight savings, or the device is on a plane and travels through timezones.
- defrost 4y ago
  Or, back when I was doing airborne geophysical surveying across the Fijian archipelago the plane would flit from -179 to +179 longitude a few times every hour with a potential change of a full day if being naive about time zones. Data aquisition instrumentation needs to use a lapsed epoch (to avoid UTC leap seconds) with a calibration at start and end of projects to adjust for drift, etc.
WhyNotHugo 4y ago
23hs or 25hs during DST transitions are the most obvious exception (twice a year in many many countries).
- MerelyMortal 4y ago

WhyNotHugo 4y ago

I've worked with calendar applications and todo managers, alarms, recurring events and all that. Our timekeeping mechanics are incredibly complex. 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. 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. 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).

Ekaros 4y ago
14h CET is 14h CET each and every time. It is just that we automatically reschedule it to 14h CEST when summertime is in use. Also it is in use for 7 months not 6 months...

cgrealy 4y ago

Does anyone actually believe this? Even the most inexperienced developers I’ve worked with are well aware that time, and timezones in particular, are really difficult. I’ve yet to meet anyone that has suggested using anything other than a battle-hardened standard library for time.

WhyNotHugo 4y ago
> Does anyone actually believe this? Does any programmer believe ALL these falsehoods? Not very likely. Do most programmers believe AT LEAST ONE of these falsehoods? Likely. > I’ve yet to meet anyone that has suggested using anything other than a battle-hardened standard library for time. Many stdlibs still don't account for the most edge of corner cases -- or make it very easy to screw up anyway.
BurningPenguin 4y ago
I once worked for a company, where the gps platform had multiple time related problems. This list pretty much sums it all up.
bee_rider 4y ago
I bet you could get me to give the wrong answer to most of these questions if you worded it cleverly in informal conversation, but the answer to anything time and date related in a technical setting is "Ugh, we'll have to look up the stupid edge cases here," right?
- cgrealy 4y ago
  Exactly. And you also need to understand your timing requirements. If all you care about is recording a date on an invoice, you really don’t need to worry about leap seconds or smearing or whatever.
yccs27 4y ago
Even if you use a library, it's easy to bake in an "obvious" assumption into your program. Such as storing location + date + time, because that should be unambiguous, right? Or confusing "same time tomorrow" with now + 24h. Are you even sure which one you need?

wodenokoto 4y ago

I think the list would be much more interesting and educational if it provided examples.

piersj225 4y ago
Jon Skeet has put together a talk on Dates and time zones talking about some examples https://www.youtube.com/watch?v=DhYUcxRWWQI https://www.youtube.com/watch?v=DhYUcxRWWQI

SwiftyBug 4y ago

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

grardb 4y ago
Here you go: https://youtu.be/-5wpm-gesOY?t=368 https://youtu.be/-5wpm-gesOY?t=368 I'd highly recommend watching the whole video, by the way. It's really good.
- idiocrat 4y ago
  Work in Finance. My year starts on April 1st. I do not want my year to start on January 1st, else I will need to work through all holidays for year-end closing.
amarant 4y ago
I don't think they mean what you think they mean. I think they mean that if someone says "remind me in a month" On December 3rd, the reminder would be next year. I've never met a developer who believed that, but I've met plenty who would forget about the edge-case and write a buggy time-library. As is the case for most of these.
slaymaker1907 4y ago
There is a concept of "week year" in Java so a given month could simultaneously exist in two (week) years.
saalweachter 4y ago
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.

dailykoder 4y ago

>Leap years occur every 4 years. 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?

atoav 4y ago
If you handle dates and times yourself on that level, prepare to be in a world of pain. Handling time and dates correctly has a similar difficulty to writing your own cryptographic primitives: If you don't know exactly what you are doing you will shoot yourself (and potentially countless others) into the foot at one in point or another.
- rocqua 4y ago
  See also the problems in the Excel datetime calculations that are now unfixable because a fix would break many existing problems. e.g. https://en.wikipedia.org/wiki/Leap_year_problem https://en.wikipedia.org/wiki/Leap_year_problem
- wruza 4y ago
  Tbh, half of my life I handled them on a financial platform which couldn’t care less of the subj list or standards. It has just ‘wall date’ like yyyy-mm-dd and ‘wall time’ strictly in 00:00:00-23:59:59 range, without a timezone. Two separate types. Never encountered of even heard of any time-related bug there. I find this simplified date/time very useful, unless you have to manage “continuous and/or real” time somehow. 99% of applications are okay with it, because they’re facing users with exactly the same mental model. Also, albeit not correct scientifically, it reflects many developers’ mental model as well. This is much better than a model that just doesn’t match, which is a world of pain. Someone adds 86400 but it’s the same day, good luck debugging it. I don’t think this is a cryptographic-level issue.
  - bee_rider 4y ago
    My uninformed guess would be that a financial platform mostly just wants a monotonically increasing clock with which to order transactions. So this would I guess avoid quite a bit of the annoying date related stuff. (?) Anyway if you queried something to get the current date-time and clock-time, you could be farming out the annoying edge cases to some arbitrarily complicated library, right? Which is the right way to do things.

Ekaros 4y ago

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.

mnw21cam 4y ago

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

r00fus 4y ago
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 https://en.wikipedia.org/wiki/British_Summer_Time
- NateEag 4y ago
  I have never had an opportunity to deploy this tool, but here's a program for generating a TZ shapefile from OpenStreetMap data: https://github.com/evansiroky/timezone-boundary-builder https://github.com/evansiroky/timezone-boundary-builder In principle a calendar program could use its output to perform GIS lookups of locations then use the tzinfo DB to get the correct timezone at the given location and specified time.

taylodl 4y ago

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 - which 1:00 - 2:00 interval are you talking about? 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. I'm so glad to be working on a system where I no longer have to worry about this crap!

UncleEntity 4y ago
During the last “fall back” event I experienced the 1 o’clock hour three times since I randomly happened to cross a time zone at exactly 2:00am…or maybe 1:00am? The worst part was I had an appointment at 02:00, somewhere where they won’t let you in if you show up too early, in the other time zone and hadn’t had to deal with daylight savings time for a good long while having lived in Arizona where they don’t deal with such silliness. Trying to figure out what time to leave to time my arrival was very difficult.
- ufmace 4y ago
  > having lived in Arizona where they don’t deal with such silliness Oh god, I'm simultaneously delighted at the idea of not having to deal with DST and terrified of writing software that might have to keep track of whether or not the user was in Arizona during a DST transition.
  - UncleEntity 4y ago
    Arizona just stays on MST year long making it easy unless you have to figure out what time everyone else is on. And for even more fun the Navajo Nation does do time zone changes.
  - 4y ago

dang 4y ago

I don't know if these are all the same falsehoods, but—related: Falsehoods programmers believe about time zones - https://news.ycombinator.com/item?id=24870376 https://news.ycombinator.com/item?id=24870376 - Oct 2020 (16 comments) Falsehoods programmers believe about time (2017) - https://news.ycombinator.com/item?id=24453712 https://news.ycombinator.com/item?id=24453712 - Sept 2020 (8 comments) Falsehoods programmers believe about Unix time - https://news.ycombinator.com/item?id=19922062 https://news.ycombinator.com/item?id=19922062 - May 2019 (268 comments) Falsehoods Programmers Believe About Time (2012) - https://news.ycombinator.com/item?id=12675527 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 https://news.ycombinator.com/item?id=11515125 - April 2016 (80 comments) Falsehoods Programmers believe about Time - https://news.ycombinator.com/item?id=4128208 https://news.ycombinator.com/item?id=4128208 - June 2012 (213 comments)

pigbearpig 4y ago
Should the link be updated to the actual source? This gist appears to just be a copy of https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time https://infiniteundo.com/post/25326999628/falsehoods-program... and https://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time https://infiniteundo.com/post/25509354022/more-falsehoods-pr... https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca#sources https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b...
- dang 4y ago
  Sure—changed from https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b... now. Thanks! (For some reason people think we know these things)
  - cwillu 4y ago
    Falsehoods hn'ers believe about dang…

bee_rider 4y ago

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

Bilal_io 4y ago
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.
- vlunkr 4y ago
  You're going to take issue with that instead of Druid part?
  - teddyh 4y ago
    I hereby announce my campaign for the role of Time Druid.
    - flir 4y ago
      Your symbols of office shall be a blinking 12:00 and the date 01-01-1970. Wait. In fact, if you weren't born on 01-01-1970, you can't be Time Druid. Sorry.
      - alexfoo 4y ago

ChrisMarshallNY 4y ago

I've just learned to do time conversions by converting from the target timezone to UST, then from UST, to the recipient timezone. Hasn't failed me yet. Here's why: https://www.nist.gov/sites/default/files/images/2019/12/23/worldzones.gif https://www.nist.gov/sites/default/files/images/2019/12/23/w... This looks useful. I haven't checked for full accuracy: https://www.timeanddate.com/time/map/ https://www.timeanddate.com/time/map/

deleted 4y ago
[deleted]

RcouF1uZ4gsC 4y ago

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

madamelic 4y ago
Here's my tl;dr for "falsehoods programmers believe about [x]" so you never have to read another: Don't make assumptions. You aren't smart. Keep it simple and don't get clever.
elcamino44 4y ago
I think I understand why you feel this way, but I personally find them to be a helpful format. For example, last time I had to figure out how to store addresses in a database I made a point to check out the falsehoods programmers believe about addresses document (as well as other sources).
iainmerrick 4y ago
I can’t stand them. It’s a smug, click-baity and passive-aggressive format, typically without any actual examples.

ddevault 4y ago

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

macintux 4y ago
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”.
- ddevault 4y ago
  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 https://docs.harelang.org/datetime#builder
  - wruza 4y ago
    Too bad that most stdlibs outscope it to third parties. Wildcard periods are essential for some applications (even as simple as a periodic reminder) and also are hard to do correctly. I’d say a period is actually more important than a date, because we mostly work with periods, and our “datetimes” are just integer coordinates of pixels of time, so to say.

LAC-Tech 4y ago

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?

madamelic 4y ago
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")
- LAC-Tech 4y ago
  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?
  - IncRnd 4y ago
    In that case, the best you can hope for is to centralize time on the server. The IoT devices can keep local differential time or contact the server (or a log server or somewhere else) at the time of the event. It's kind of messy, since you are asking to trust a client's data, which is untrustworthy.
- rcoveson 4y ago
  > 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.
- askvictor 4y ago
  Have had plenty of problems with WPA-Enterprise auth refusing to join a wifi network on account of a wildly wrong computer time. Which in turn means that the computer can't get a correct time on account of not being able to ask an NTP server.

thenightcrawler 4y ago

I'd like to hear about how to write software orbiting a black hole?

marcosdumay 4y ago
As long as you don't change orbits, you should be fine.
- SilasX 4y ago
  "Falsehoods programmers believe about black hole orbits..."
mhh__ 4y ago
Very carefully indeed
NovemberWhiskey 4y ago
I mean, you're sort of there already? The galactic barycenter is a supermassive black hole called Sagittarius A*.

behnamoh 4y ago

Similar thing for Names: Falsehoods Programmers Believe About Names https://news.ycombinator.com/item?id=1438472 https://news.ycombinator.com/item?id=1438472

pvg 4y ago
The Unreasonable Effectiveness of Falsehoods Programmers Believe Considered Harmful https://news.ycombinator.com/item?id=3735928559 https://news.ycombinator.com/item?id=3735928559
- zdwolfe 4y ago
  Is this link correct? I get a 404.
  - pvg 4y ago
    So harmful they had to censor it.
- anon_123g987 4y ago
  Awesome Falsehood - A curated list of falsehoods programmers believe in https://github.com/kdeldycke/awesome-falsehood https://github.com/kdeldycke/awesome-falsehood

andyferris 4y ago

I always enjoyed an entertaining talk by Peter Hall on this subject: https://youtu.be/bJmx0tcVubY?t=3224 https://youtu.be/bJmx0tcVubY?t=3224

uniqueuid 4y ago

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.

takinola 4y ago

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.

at-fates-hands 4y ago
I personally have not had much experience with it. Would love to hear some horror stories you've encountered. It might help me keep an eye out for it.
- jamesfinlayson 4y ago
  Trying to deal with conversion between time zones or to/from daylight saving can have gotchas which libraries will deal with for you.
bentcorner 4y ago
I agree. I'd wager most programmers don't need to actually worry about calendars, but most occasionally need to worry about time. Just use a library and read the docs for what to expect to happen when you do something like getCurrentTime. What is the resolution, does it monotonically increase, etc. If you actually need to worry about calendars and user input, you have my sympathy.
- mjevans 4y ago
  Handing those cases correctly might very well be a Turing test...

gillesjacobs 4y ago

> 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=UTC%20is%20not%20a%20time,UTC%20as%20a%20local%20time https://www.timeanddate.com/time/gmt-utc-time.html#:~:text=U....

naniwaduni 4y ago
Still subject to IERS whims, though.
- gillesjacobs 4y ago
  Sure but governments can and do change timezones more regularly than programmers keep up [1]. In 2014, Egypt's new government changed their timezone with only a week notice. Updating standards almost never happens, unless with a name/identifier change. The whole point of standardized measures is their immutability. [1] https://www.timeanddate.com/news/time/ https://www.timeanddate.com/news/time/ [2] https://english.ahram.org.eg/News/100735.aspx https://english.ahram.org.eg/News/100735.aspx
deleted 4y ago
[deleted]

suzzer99 4y ago

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.

ccooffee 4y ago
Many years ago, a user filed a bug report that the timezone information we used for historical places in Indiana was incorrect. I don't remember exactly what the user was doing, but I think it had something to do with train schedules or something. I did not fix that bug. (But I did learn that the 'TZ' database has this information, though I think 'America/Indiana/*' had been pruned out of the copy our JVM was using.)
- IncRnd 4y ago
  Some of Indiana is on the Central Timezone and some is on the Eastern Timezone. This is definitely an issue!

kristopolous 4y ago

The "opportunity for bugs" I didn't realize until I was over 10 years into my professional career: 10 AM 11 AM 12 PM <- AM/PM and calendar cycle is here. 01 PM <- n%12 cycle is here, an hour later. 02 PM 03 PM 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 negative 11 hours. 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. 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.

not2b 4y ago
I missed a plane flight once because an admin for the company I was working with booked a midnight flight accidentally and I thought it was at noon (I think she thought so as well). I think it was in the 90s sometime.
- UncleEntity 4y ago
  Not very long ago I showed up to an appointment at 7:00 am and was told it was really at 19:00 — and our computer system uses 24 hour time so obviously someone just screwed up the conversion. Midnight appointment are interesting since the system doesn’t have “no appointment time” so they use 00:00 and 00:01 for a real midnight appointment and if you’re really, really tired…
gsich 4y ago
am/pm users have lost their sanity.
- BonoboIO 4y ago
  I m surprised it’s not 7 inch past 12
BurningFrog 4y ago

leecommamichael 4y ago

The proposed moral of this story, and those like it, is to avoid re-implementing general-purpose libraries. 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.

DiggyJohnson 4y ago
I think your comment makes sense for pretty much any domain other than timekeeping though, and to claim otherwise is to take nothing away from TFA.

kortex 4y ago

Python specific: - `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? What `pytz.timezone(name)` actually 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 >>> pytz.timezone('America/New_York') <DstTzInfo 'America/New_York' LMT-1 day, 19:04:00 STD> 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 >>> pytz.timezone('America/New_York').localize(your_specific_datetime) Timezones without a reference time are deceptive. [1] https://en.wikipedia.org/wiki/Tz_database#Example_zone_and_rule_lines https://en.wikipedia.org/wiki/Tz_database#Example_zone_and_r...

hermitdev 4y ago
Can probably add another falsehood: that timezone information (in particular DST & UTC offsets) will never change. In reality, timezones are very much political and can change at any time with sometimes very little notice. Last major change US folks may remember occurred around 2007, when daylight saving time was expanded by 6 weeks. I know of clocks that are still wrong from that change. At a previous job, I spent over a year working on a library for timezones built on top of Boost. The handling of historical timezones was a particular pain in the ass.

icedchai 4y ago

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.

fingerlocks 4y ago
> Tons of code converting back and forth between ints. Code was a mess. Never experienced this myself, it’s trivial in all the languages I can think of. Sometimes you have multiply or divide by 1000 if JavaScript is involved. I always prefer Unix epoch time. What was the language and stack causing the mess so I know to avoid it?
- icedchai 4y ago
  The code was a mess for other reasons beyond the int/timestamp conversions. In some places it was stored as milliseconds, other places seconds. It was python 2 if it matters.

donatj 4y ago

> The system clock will always be set to the correct local time. I work on a sometimes offline educational product for children. Kids for some reason love to mess with their system clocks. 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. 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.

Retr0id 4y ago
> Kids for some reason love to mess with their system clocks. There are plenty of mobile games that will time-gate in-game rewards (e.g. wait x hours to unlock y). Often, messing with the system clock skips these delays. You're welcome.
IncRnd 4y ago
> Kids for some reason love to mess with their system clocks. They are cheating at games!
dekleinewolf 4y ago
My dad has some insomnia problems and used to play a lot of Candy Crush. His iPad was like 2 centuries ahead because moving the system time would give him extra lives. He couldn't practically move it back because then he'd have to wait another 2 centuries to get lives again. So his iPad was 2 centuries ahead until he completed Candy Crush.

CliffStoll 4y ago

Of about 96 entries, I count 27 instances of "Always" and 12 instances of"Never" Reminds me of the old SAT hints: Beware of statements and questions with "always", "never", "must", and "cannot".

decebalus1 4y ago

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. Sure, you might run into some quirk at some point in your career but they will end up being just another weird war story. 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 https://news.ycombinator.com/item?id=32335165 https://news.ycombinator.com/item?id=32335165.

gweinberg 4y ago

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

pjscott 4y ago
Agreed on all counts. The “falsehoods programmers believe about X” articles are cautionary lists of edge cases to think about, with an unfortunately aggressive naming scheme.
- ryandrake 4y ago
  They should really call these lists "Incorrect assumptions programmers make about X" or: "Test cases programmers should test their software against"
  - mgkimsal 4y ago
    Or “boundaries users have to stay within”. I’m aware of a lot of edge cases. When you start building with those in mind, it adds complications. Extra steps or more UI or whatever, to ensure the “right” thing happens, assumptions are obvious, etc. More often than not I’m pushed back in with “that doesn’t happen” or “don’t spend time on that”. “We’re never open past 9, don’t worry about a day” but then they acquire a system in a different time zone and … boom. Things are broken.
- fomine3 4y ago
  Falsehoods programmers Considered harmful
jerf 4y ago
There are the things you say you believe, and there are the things your actions show you believe. This extends well past simple matters of time in computers. Some of my favorite things lie in the fractal fringe categories between those, such as, "the things you didn't realize you believed (by your actions) until someone pointed them out to you" and "the things you didn't realize you should believe (in any sense) until someone pointed them out to you, at which point they seemed blindingly obvious and you can't believe you missed it".

wyldfire 4y ago

> The day of the month always advances contiguously from N to either N+1 or 1, with no discontinuities. I would've presumed this one - for the Gregorian calendar, at least. What are some counterexamples?

bobbylarrybobby 4y ago
Well, if by day advancing you (they) mean adding 24 hours to a given datetime, then a 23 hour day would cause the date to advance by two.
NateEag 4y ago
See e.g. the British transition from Julian to Gregorian calendars, in which eleven days of September 1752 were not observed in England: https://en.m.wikipedia.org/wiki/Calendar_(New_Style)_Act_1750 https://en.m.wikipedia.org/wiki/Calendar_(New_Style)_Act_175... IIRC, that event is the reason SQLServer's datetime type is only good back to 1753, and thus why you should use datetime2 for dealing with older historical dates: https://database.guide/datetime-vs-datetime2-in-sql-server-whats-the-difference/ https://database.guide/datetime-vs-datetime2-in-sql-server-w...

joshthecynic 4y ago

dkbrk 4y ago

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. Then, there would be only three problems, which decompose nicely: 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. (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. 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. 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.

Tepix 4y ago
If the system time isn't accurate most of the problems would still apply.
deleted 4y ago
[deleted]

cwillu 4y ago

Falsehoods programmers believe about falsehoods: * Something is a falsehood because it's not true in every context * Something is a falsehood because it's not true in many contexts * Something is a falsehood because it's not true in any context but the one the programmer cares about (and the correct context is often “whatever deals with the company's bullshit problem with the least effort”)

rzimmerman 4y ago

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

hoseja 4y ago
One glorious day we'll switch to outside-of-gravity-well coordinated reference time frame.

dekleinewolf 4y ago

Just wait till you hear about leap seconds. 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.

seabea 4y ago
Meta (among others) want to change that. https://engineering.fb.com/2022/07/25/production-engineering/its-time-to-leave-the-leap-second-in-the-past/ https://engineering.fb.com/2022/07/25/production-engineering...