[netsharc]

The article gives an example, of you buying a coffee with your credit card while travelling to Sydney, and returning to Madrid, and a few months later seeing a charge for 3:50 AM on that date...

Google Photos also get confused with "When was this picture taken?", my older model camera just stores the EXIF date in "local time" and I have to remember to change its timezone when travelling, and if GPhotos can't figure it out, it might show pictures out of the airplane window, and then the next series of pictures are from the departure airport because they're from a "later" hour (since it's missing the timezone info).

I suppose I could keep it at my home time or UTC...

[chuckadams]

And if your spouse is checking the charges from Madrid, they probably want to see it in Madrid time. There is no single correct answer.

[lxgr]

Exif (fun exercise: find out who specifies it and when it was last updated!) actually didn't even have a way of storing timestamps in UTC or with zone information until fairly recently: It was all local times without zone information.

I've seen some software work around that by combining the local date/time with an embedded GPS tag, if present, which does contain the time in UTC.

[mlhpdx]

Ironically, time zones are a hack with bad precision about the position of the sun in the sky. The GPS coordinate side steps the nonsense (can be converted to the time zone as defined in that place at that moment).

[mminer237]

That is how I would expect a bank statement to read though. I would find it infinitely more confusing if I bought something online in my bank showed the time of wherever the seller was located.

The photos problem is harder, but the app needs to just convert it from local time to UTC when you import it. There's not much that can be done if you take photos on a camera with a different time zone than you're in without more metadata.

[lxgr]

You'll find that most bank systems avoid any notion of time precision higher than calendar days for a variety of reasons :) As a side effect, this practice conveniently avoids that problem entirely.

> That is how I would expect a bank statement to read though. I would find it infinitely more confusing if I bought something online in my bank showed the time of wherever the seller was located.

When using my banking app abroad (one that does show timestamps), I'm usually much more confused by their presence than by their absence.

> The photos problem is harder, but the app needs to just convert it from local time to UTC when you import it.

But I usually want to see the time in local hours and minutes for photos! Sunsets, new year's fireworks etc. happen according to local time, not UTC or my current timezone's offset.

[mminer237]

Yeah, storage needs to be implemented in UTC and display needs to be in local time.

[lxgr]

But which local time?

Sometimes, the local time at the place the photo was taken can make more sense, but it's not a general rule.

[netsharc]

Yeah, these are workarounds we have to use because many pieces of software weren't implemented fully...