Navigating the timezone nightmare in product development

This is a topic I often see overlooked from the user perspective and I'm happy to see more discussion about this.

My anecdote: when I was working for a B2C startup we had to ensure we billed customers on the correct date, like OP. Timezones are hard; dates are easy (or so we thought). When we billed a customer on their billing date we had to attempt to take payment at a time, which meant that our naive date handling converted that date into midnight UTC on that date, causing many western European customers to be billed at 23:00 or earlier on the previous day from their perspective.

Furthermore, from the operations side we were often dealing things that happened "on a date". I was pushing for at least our internal customer service systems to present two timestamps to agents: the date and time at which the thing occurred in the place that event occurred and also the date and time at which the thing occurred in the customer's location. For example, something being changed about a customer's account at 23:55 in London on a Monday actually happened at 00:55 on Tuesday for the customer in France. However, the timezone information was either not stored or not presented, interfaces were not consistent, and the result was pot luck whether the customer or a member of the customer service team would see Monday or Tuesday.

Timezones are hard. Presenting that information in a contextually appropriate way to your own employees and customers can be just as hard.

I like that the authors of the article have reached similar conclusions, especially around "dates have timezones". I think datetime capture and presentation is a fantastic UX topic.

It's solved, in that I'm never going to do better than zoneinfo and I'm not going to go crazy trying.

https://en.wikipedia.org/wiki/Tz_database

https://www.iana.org/time-zones

I think of this as "difficulty snap back": Things can only get so difficult before everyone punts and uses some external library.

Yeah, I often like to emphasize that many "scheduled events" are not simple numbers, but pattern-matching conditions, a contract of triggering-rules for something an unknowable number of elapsed seconds from "now."

To be specific, it's "whenever the desk-calendars and wall-clocks in that jurisdiction will say X because the local government says so."

The government of Bizarro São Paulo could decide to pause the clocks at 1:00PM, wait for one sunset and one sunrise, then set their clocks to 12:00PM, and then advance it by one "minute" every time a rooster crows until it reaches 12:10pm at which point they skip straight to 3:00pm.

When is your schedule your 2PM wall-clock meeting? Probably around the tenth rooster-crow. If you had reason to distrust the clock-culture of Bizarro São Paulo, you shoulda made it a different timezone. :P

Another detail about dates people often forget or don't know (though it's not usually important), is that a "date" can be 50 hours long. Let's say you want to have some sale to occur all day on Christmas, midnight to midnight in your customer's local time.

For easier math let's say your business is in GMT tz. People in the Line Islands (Pacific/Kiritimati) will have access to the sale 14 hours before yourself. Then the sale-time occurs in GMT, 24 hours pass, and the sale ends in GMT. But people in American Somoa (Pacific/Midway) will still have the sale active for 11 hours. (Technically someone using satellite internet in the open ocean east of Samoa has 12 hours, but the UTC+12 timezone is completely uninhabited).

Such a sale is kind of a farfetched example, but I've encountered this issue when trying to do analytics reports looking at user data that happens on specific global holidays.

> Time Zones often have a "friendly name" in the format Continent/City|Island

Continent/City are not friendly names, they are political boundaries that gice more precision. For example, CET covers many countries that might decide to stop applying DST at different points in time. If you store CET in your database you won't know if you need to apply CEST or not. This is why you always need the Continent/City form if you want to be future proof (and past proof)