Traveling internationally so much, I learnt to deal with timezones early.
In the 90s I was already appreciative of Linux's approach of "set the system clock to UTC" and treat the translation to the local timezone as a display issue.
Windows was terrible at this which led to all sorts of interesting filesystem issues when changing timezones.
It is tempting (and I've heard many people say this) to think that "store as UTC and treat translation to local timezone as a display issue" is the end of the matter. But my experience over the last few years says otherwise.
Firstly, times relating to an event that people are going to physically be at (such as a conference) should probably be in the local time of that event, regardless of the timezone of the user looking at the website for that event.
However note that something like a CFP deadline might be localized. So it's very context-dependent.
Secondly, for something things like alarms or recurring reminders to do something at X a.m. every day, you might want that to always be in "naive" local time. If I want to go to bed by 10 p.m. every night, I mean in whatever local timezone I'm in. I don't want to store 10 p.m. as 3 a.m. UTC and then have it mean 7 p.m. when I'm on the west coast of the US.
But perhaps the most interesting subtlety I've noticed so far about this is that there are somethings such as daily streaks which are not timezone invariant. I first noticed this when GitHub and the (now down) Calendar About Nothing were reporting streaks on GitHub commits. They reported completely different numbers.
The reason is that GitHub calculated day boundaries in Pacific Time and Calendar About Nothing calculated day boundaries in UTC.
That means if I did a commit at 11 p.m. on Monday night (Pacific Time) then the next commit at 1 a.m. on Wednesday morning (Pacific Time) I would have broken my streak on GitHub (no commit on Tuesday) but continued my streak on Calendar About Nothing (a commit on Tuesday at 7 a.m. and another on Wednesday at 9 a.m.)
So a streak number is dependent on timezone. If you tried to localize that (which you may want to do: if my goal is to go to the gym everyday, I clearly mean in my timezone) then you would want to store not just the UTC time but the time in the particular timezone the person was in. You don't want a change of their timezone setting to change their streak score.
So "just store in UTC", while solving many problems, is not always the way to go. In many cases, there's more to it than that.
Github recently announced they're moving to Timezone-aware contribution graphs.
I was initially nervous for the reasons given above, but Dirkjan Bussink put my fears to rest via Twitter.
It sounds like they're doing it right by recording the timezone of the contribution rather than normalizing it and localizing it on display.