[sigwinch28]

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.

[squeaky-clean]

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.

[throw-ru-938]

And when you interact with people 8 time zones away, concepts like "today" or "tomorrow" break down completely. It's a very uncanny feeling.

[midasuni]

I remember having a call with two colleagues once, I was in Sydney, one colleague was in london and one in LA

It was quite surreal, although time wise I think the LA person was up early on Tuesday and I was up late.

[squeaky-clean]

One member of my D&D group moved to Denmark, one moved to Tokyo. The rest of us are on the US east coast. We have the hang of it now, but for our first few online sessions there was always someone who missed it because they showed up a full day late or early.

It's also funny how some of the group is having coffee and breakfast while other members are getting drunk and having midnight snacks.

[bradknowles]

On the project I'm on now, we have regular weekly meetings like that. One guy in the UK, one guy in the DC area, me in Texas, another guy in Seattle, and another guy in Sydney. Plus possibly some other people that might also join from some of those same timezones.

I now have an app that runs continuously in my menu bar to track all the different time zones that I care about. Tel Aviv and Tokyo also figure into the equation sometimes.

[hrrsn]

> the UTC+12 timezone is completely uninhabited

New Zealand would like a word.

[PlunderBunny]

If it was a burn, it was pretty hot.

[Denvercoder9]

The thing with dates depends on the context though. A birthday for example isn't associated with a timezone.

[Rafsark]

That's true, but wishing a birthday at the right moment depends on the timezone. It's not just about the date itself, it's about the interactions other people have with this date

[Rafsark]

Completely true. I think the main point of your comment is about "presenting that information contextually to customers". You often have to make choices when you decide to bill your customers, and those choices have to be crystal-clear to your end users. When I was working for a neo-bank, 50% of the complains was about billing not being clear, and timezones was one of the top reasons.

[coldcode]

When I worked at an online travel agency building our iOS app, dates were a giant pain in the ass. What is today? What is tomorrow? I covered it at https://thecodist.com/what_time_is_tomorrow_tales_from_the_t...