171–180 of 212 posts
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…
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/
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)…
> 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?
> 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?
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…
No programmer has ever cared about Lady Day when writing a program. And if they did, by definition, they would understand it's significance.
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.
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.
Earlier quoted context omitted.
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…
"Falsehoods programmers believe about X" articles inevitably become a discussion about niche anthropology facts. No programmer has ever cared about Lady Day when writing a program. And if they did, by definition, they would understand it's significance.
It's not crazy to think that a user may, say, want to create a database of historical records, like when people were born, married or buried. Now I want to find out the age people were when married... suddenly, the existence of Lady Day and the time and place the dates were recorded become very important.
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…
am/pm users have lost their sanity.
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, whi…
I also worked on event planning software with plenty of timezone fun with events having a timezone, the planner a potentially different timezone and it also handled flights for speakers etc who could be coming from any number of other timezones. That was mostly straight forward with decent libraries, but it certainly taught me that you need to think in (and store) timezones and not just offsets.
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'd say that the best solution would be to just rename 12 to 0, which is what it already should have been IMO, regardless of am/pm.
I've noticed some digital watches use 0:00AM instead of 12:00AM, but I've never seen this used for 0:00PM.