Proper caching makes any problem 10x as hard.

This has to come with a trigger warning.

“Our JavaScript date library and the date library we’re using in Clojure disagree on the first day of the week. Elasticsearch disagrees with both too”

You can avoid this problem by always passing in either a time or a time provider and never just relying on Time.now or whatever it is your language provides.

Funnily enough, I recently had to help with an issue where a company's payment screen was not loading correctly and instead displaying "Invalid session". They use a third-party vendor to handle payments and display their payment form in an iFrame on their website.

There is an initial request to create a session that has to pass the desired expiration time of the session. Unfortunately, the vendor requires the time to be in Eastern Time. The poor, naive soul that originally implemented this just got the current date, added 15 minutes, and converted it to "EST". As soon as daylight savings hit a few weeks ago, the expiration time was automatically being set to 45 minutes in the past, the vendor was responding with "Invalid Session" and the company was unable to take payments from customers.

I recently came across a 15 year old bug in qt involving both time comparison _and_ cache invalidation: the code was trying to set timers to fire when the next cache entry was set to expire, but the timeout was in seconds while the eviction code compared milliseconds. The result was 100% cpu usage for up to a second as the timer spun without evicting the cache entry.

Funny related story: For an internship, I worked on a app that would show your sleep data in a nice visualization (this was for a smartwatch). I implemented a basic version, and used it for a few weeks. It seemed to work fine for me, so I released a beta version for others in the company to dog food.

Within a day, I got a bug report from a coworker that it rendered incorrectly for them. I was pretty surprised, since I had been using it for a long enough that I would have expected to encounter all the edge cases.

I dug into the code, and realized that this bug only happened if you went to sleep before midnight, which I never did...

It is - do your sorting, then show the results to stakeholders and you’ll see they all want different, mutually conflicting sort orders.

I see a transaction rolled back, and the autoincrement id column no longer matches the row count.