[HN Gopher] Falsehoods programmers believe about time
___________________________________________________________________
Falsehoods programmers believe about time
Author : rrampage
Score : 82 points
Date : 2022-08-22 06:39 UTC (16 hours ago)
(HTM) web link (gist.github.com)
(TXT) w3m dump (gist.github.com)
| RcouF1uZ4gsC wrote:
| 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 wrote:
| 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 wrote:
| 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).
| mnw21cam wrote:
| > 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 wrote:
| 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
| gillesjacobs wrote:
| > GMT and UTC are the same timezone.
|
| I got one for OP, too: UTC is not a timezone in the first place
| [1].
|
| > UTC is not a time zone, but a time standard that is the basis
| for civil time and time zones worldwide. This means that no
| country or territory officially uses UTC as a local time.
|
| The difference is subtle, but a standard is not subject to
| government whims while a timezone is.
|
| 1. https://www.timeanddate.com/time/gmt-utc-
| time.html#:~:text=U....
| naniwaduni wrote:
| Still subject to IERS whims, though.
| kristopolous wrote:
| 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.
| ddevault wrote:
| We're developing a new date/time library from scratch for Hare.
| So far I think we're doing a pretty good job. The person leading
| up this effort (Byron Torres) has written up a blog post about it
| here:
|
| https://harelang.org/blog/2022-04-17-chronology-in-hare/
|
| To stress test our implementation (and to flex on other
| languages), we're implementing Martian time in it as well.
|
| https://harelang.org/blog/2022-08-01-martian-time-in-hare/
| // Hare's first commit. let hare = mbc::new(chrono::MTC,
| 0, 0218,10,19, 09,20,53,344357297)!;
| fmt::println(mbc::bsformat(buf, mbc::STELLAR, &hare)!)!;
| // 0218 Perseus 19, Fri 09:20 MTC
|
| My current litmus test goal for it is to get strftime to print
| out 23:23:60.
| macintux wrote:
| 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 wrote:
| 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
| wruza wrote:
| 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.
| suzzer99 wrote:
| 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 wrote:
| 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.)
| leecommamichael wrote:
| 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.
| LAC-Tech wrote:
| _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 wrote:
| 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 wrote:
| 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?
| rcoveson wrote:
| > 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.
| bennyp101 wrote:
| "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?
| Quekid5 wrote:
| Others have already answered this one, but somewhat relevant:
| https://www.timeanddate.com/date/february-30.html
| pointlessone wrote:
| Adoption of the Gregorian calendar [1] resulted in a number of
| short months in a bunch of countries.
|
| Different but related, 46 BC, the year of adoption of the
| Julian calendar, had 15 months [2].
|
| [1]:
| https://en.wikipedia.org/wiki/Adoption_of_the_Gregorian_cale...
|
| [2]: https://www.uh.edu/engines/epi2364.htm
| jwie wrote:
| I suppose it depends on if you think about a "fact month",
| that is the series of days people experience, or the formal
| calendar months as the things being handled by the system.
|
| The daylight savings time transition doesn't "shorten" or
| "lengthen" the day, it merely transforms the clock. The day
| isn't 25 hours or 23 hours. This is essentially the same
| thing as the Julian/Gregorian swap. The day didn't really
| change, just the system we use to understand what day it is.
|
| The span of time users experienced was weird, but this wasn't
| the unit of time being shorter or longer. It's an artifact of
| the transition not anything happening to the time.
|
| A lot of these falsehoods on the list can be side stepped by
| distinguishing between the dimensions and the facts about
| representing time.
| astrobe_ wrote:
| That's what I thought. This list mixes "falsehoods" that
| nobody with a bit of common sense - even children - would
| believe, and pedantry that _could_ be useful to 0.001% of
| developers. For most programs, Time starts in 1970.
|
| IMO, this list is only good at... wasting time. Except for
| the multiple statements (that could be one or two) that point
| out that there's not such a thing like "identical clocks" and
| "same time on two clocks".
| wink wrote:
| So "most" programs can ignore birth dates of people older
| than 52? I don't think so.
| trentgreene wrote:
| Do most programs need to know the birth date of the user?
| thfuran wrote:
| Most of the programs I write do. Well, of people, but not
| typically the user.
| HiIAmIlNano wrote:
| If I am not wrong this holds true for the switch from Julian
| calendar to the Gregorian one. Some months were shortened to be
| synchronised with the new system. And if I am not mistaken
| Jewish and Arabs do not use the same systems we use for months
| and years
| defrost wrote:
| For an added twist this changeover occurred in different
| years, at different times in different countries .. and not
| always with the same number of days difference.
|
| Good Times.
| Ekaros wrote:
| And even more good times. It seems sometimes some countries
| went back to Julian...
| n4r9 wrote:
| Clicking through the links, this post appears to be the source:
| https://news.ycombinator.com/item?id=4128470
|
| As another commenter noted, the exception appears to be
| September 1752.
|
| That's a fun example but whether it's worth worrying about is
| another question...
| teddyh wrote:
| As the comments to that comment points out, 1752 is only _for
| one specific country_. All countries switched at different
| times (and a few even switched back and forth a few times).
| Greece, in particular, seems to have switched as late as
| _1923_.
| TylerE wrote:
| Russia is a big one too, especially for early 20th century
| history nerds.
|
| They used the Julian calendar until after the Revolution,
| so when reading accounts of, say, most of WW1, Russian
| sources have dates that are 13 days off from Western
| sources. This leads to much confusion when authors don't
| make it clear they've converted the dates (or not).
|
| Amusingly, one of the first casualties of this was the
| October Revolution, which in the new (Gregorian) calendar
| actually occurred on November 7th
| [deleted]
| bennyp101 wrote:
| Ah ok cool - thanks for the replies!
|
| So I guess its not really something that I need to worry about!
| k4rli wrote:
| Maybe they're developing software to be used on Mars? 687 day
| years mentioned in Gist comments.
| Schroedingersat wrote:
| 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 wrote:
| 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 wrote:
| September 1752
| NeoTar wrote:
| 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_adoptio
| n_dates_of_th...
| detaro wrote:
| 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.
| pointlessone wrote:
| Lunar month is a little over 29 days on average. And most
| lunar calendars do not align with solar year but rather have
| leap months added. E.g. Hebrew calendar [1].
|
| [1]: https://en.wikipedia.org/wiki/Hebrew_calendar
| detaro wrote:
| Ok, you made me look up an example: "The Ethiopian calendar
| has twelve months of thirty days plus five or six
| epagomenal days, which comprise a thirteenth month."
|
| https://en.wikipedia.org/wiki/Intercalation_(timekeeping)
|
| https://en.wikipedia.org/wiki/Ethiopian_calendar
|
| I guess its the choice if you fix the offset every year or
| wait until you accumulate a full month of offset.
| thenightcrawler wrote:
| I'd like to hear about how to write software orbiting a black
| hole?
| mhh__ wrote:
| Very carefully indeed
| marcosdumay wrote:
| As long as you don't change orbits, you should be fine.
| SilasX wrote:
| "Falsehoods programmers believe about black hole orbits..."
| takinola wrote:
| 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 wrote:
| 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.
| bentcorner wrote:
| 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.
| yreg wrote:
| 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 wrote:
| 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]
| edent wrote:
| 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 wrote:
| But the point is that programmers are _less_ likely to
| believe these things than ordinary people are.
| xboxnolifes wrote:
| By putting the intended audience in the title, you grab
| their attention more.
| yreg wrote:
| 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
| xboxnolifes wrote:
| Its not click bait, the contents are what the title claim
| to be.
| edflsafoiewq wrote:
| 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 wrote:
| But they're more likely to be impacted.
| bryanrasmussen wrote:
| 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 wrote:
| Programmer that have worked with timekeeping: yes.
|
| Average programmer who hasn't done anything datetime-specific:
| unlikely.
| SwiftyBug wrote:
| > 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?
| slaymaker1907 wrote:
| There is a concept of "week year" in Java so a given month
| could simultaneously exist in two (week) years.
| grardb wrote:
| Here you go: https://youtu.be/-5wpm-gesOY?t=368
|
| I'd highly recommend watching the whole video, by the way. It's
| really good.
| idiocrat wrote:
| 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 wrote:
| 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.
| saalweachter wrote:
| 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.
| kortex wrote:
| 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').locali
| ze(your_specific_datetime)
|
| Timezones without a reference time are deceptive.
|
| [1]
| https://en.wikipedia.org/wiki/Tz_database#Example_zone_and_r...
| dang wrote:
| 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 - Oct 2020 (16
| comments)
|
| _Falsehoods programmers believe about time (2017)_ -
| https://news.ycombinator.com/item?id=24453712 - Sept 2020 (8
| comments)
|
| _Falsehoods programmers believe about Unix time_ -
| https://news.ycombinator.com/item?id=19922062 - May 2019 (268
| comments)
|
| _Falsehoods Programmers Believe About Time (2012)_ -
| https://news.ycombinator.com/item?id=12675527 - Oct 2016 (154
| comments)
|
| _Falsehoods programmers believe about time and time zones_ -
| https://news.ycombinator.com/item?id=11515125 - April 2016 (80
| comments)
|
| _Falsehoods Programmers believe about Time_ -
| https://news.ycombinator.com/item?id=4128208 - June 2012 (213
| comments)
| pigbearpig wrote:
| Should the link be updated to the actual source? This gist
| appears to just be a copy of
| https://infiniteundo.com/post/25326999628/falsehoods-program...
| and https://infiniteundo.com/post/25509354022/more-falsehoods-
| pr...
|
| https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b...
| behnamoh wrote:
| Similar thing for Names:
|
| Falsehoods Programmers Believe About Names
| https://news.ycombinator.com/item?id=1438472
| pvg wrote:
| _The Unreasonable Effectiveness of Falsehoods Programmers
| Believe Considered Harmful_
|
| https://news.ycombinator.com/item?id=3735928559
| zdwolfe wrote:
| Is this link correct? I get a 404.
| anon_123g987 wrote:
| Awesome Falsehood - A curated list of falsehoods
| programmers believe in
|
| https://github.com/kdeldycke/awesome-falsehood
| taylodl wrote:
| 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!
| bee_rider wrote:
| 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 wrote:
| 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.
| uavals wrote:
| vlunkr wrote:
| You're going to take issue with that instead of Druid part?
| teddyh wrote:
| I hereby announce my campaign for the role of Time Druid.
| flir wrote:
| 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 wrote:
| Do you mean 01-01-1970 or 01-01-1970?
| ravi-delia wrote:
| And why do only people born within them get special hats?
| Maybe you and I have the privilege of going about hatless,
| but not the majority of the world.
| lenova wrote:
| First they came for the Special Hats, but I did not speak
| out -- because I was hatless...
| bee_rider wrote:
| Ah details, the Time Druids will sort that out probably.
| suzzer99 wrote:
| The Maya did this. Those last 5 orphaned days of the year were
| considered very bad luck. You did not want to be born in that
| period.
| LanceH wrote:
| This sounds like an excellent first step into imperial units.
| NegativeLatency wrote:
| Something very similar already exists (in theory):
| https://en.wikipedia.org/wiki/International_Fixed_Calendar
|
| Kodak used to run on this calendar.
| account-5 wrote:
| I was going to mention this. 13 months each with 28 days.
| hanney wrote:
| Lousy Smarch weather (doh!)
| ddevault wrote:
| https://qntm.org/calendar
|
| See also: https://qntm.org/continuous and
| https://qntm.org/abolish
| bee_rider wrote:
| Hmm the only one which seems to apply is:
|
| > having one or two days per year which are part of no month
| is stupid
|
| which I've cleverly circumvented by adding almost a while
| week. I believe in this case the stupidity overflows and it
| becomes a good plan again.
| icedchai wrote:
| 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.
| dailykoder wrote:
| >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 wrote:
| 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.
| wruza wrote:
| 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.
| rocqua wrote:
| 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
| shafyy wrote:
| > _There are always 24 hours in a day._
|
| Is this referring to leap seconds or what do the mean?
| jstanley wrote:
| 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 wrote:
| Makes sense, thanks!
| _dain_ wrote:
| Daylight savings, or the device is on a plane and travels
| through timezones.
| defrost wrote:
| 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 wrote:
| 23hs or 25hs during DST transitions are the most obvious
| exception (twice a year in many many countries).
| MerelyMortal wrote:
| Sometimes 22hrs or 26hrs if traveling by ship.
| ChrisMarshallNY wrote:
| 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/w...
|
| This looks useful. I haven't checked for full accuracy:
| https://www.timeanddate.com/time/map/
| Ekaros wrote:
| 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.
| WhyNotHugo wrote:
| 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 wrote:
| 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 wrote:
| 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.
| bee_rider wrote:
| 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?
| BurningPenguin wrote:
| I once worked for a company, where the gps platform had
| multiple time related problems. This list pretty much sums it
| all up.
| yccs27 wrote:
| 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?
| WhyNotHugo wrote:
| > 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.
| wodenokoto wrote:
| I think the list would be much more interesting and educational
| if it provided examples.
| piersj225 wrote:
| Jon Skeet has put together a talk on Dates and time zones
| talking about some examples
|
| https://www.youtube.com/watch?v=DhYUcxRWWQI
| andyferris wrote:
| I always enjoyed an entertaining talk by Peter Hall on this
| subject: https://youtu.be/bJmx0tcVubY?t=3224
| uniqueuid wrote:
| 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.
___________________________________________________________________
(page generated 2022-08-22 23:00 UTC)