161–170 of 212 posts
* 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”)
Earlier quoted context omitted.
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...
Sure—changed from https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b... now. Thanks! (For some reason people think we know these things)
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 1…
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.
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)…
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?
> 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?
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-w...
The "opportunity for bugs" I didn't realize until I was over 10 years into my professional career: 10 AM 11 AM 12 PM 01 PM 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 chan…
I know, I can look it up, and I have several times. But the knowledge doesn't stick...
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.
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".
> 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.
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://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.
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…
Earlier quoted context omitted.
The Icelandic calendar used to be something like that before the adoption of the Gregorian calendar in the 18th century (Iceland actually skipped the Julian calendar entirely, although I believe the old calendar was actually heavily inspired by the Julian). All years were 12 months of 30 days plus 4 extra days of summer ( Sumarauki in Icelandic), making the year exactly 52 weeks. Leap years had one extra week added t…
I'm certainly romanticizing the whole thing but given, > There is no special numbering of the years used in the Icelandic calendar, so the year may be omitted or the current Gregorian year used. It is hard not to imagine a day in Sumarauki as being sort of magically timeless.