As the article hints, even though timezones are usually presentation-only, there are some cases where business logic really does have to deal with timezones.
If your software has business logic that cares about, say, what day a specific person perceived an event as happening, it needs to think about the timezone they have set.
So, in such cases, you'd better keep a history of all the timezones they've ever chosen, and the time (UTC) they changed them.
(Hopefully this lets someone else avoid my past mistakes.)
I would go so far as to say that time zones are rarely presentation-level issues. Want to have a meeting every Tuesday at 2:00 New York time? Better make sure you know the New York part or daylight savings will break it. Want to wake up every day at 9:00? If you don't track the zone that preference is set in, you won't get that right when you travel. Time zone isn't a presentation-only thing because people's behavior depends on their time zone.
Agreed. Often you need to care about timezones. Someone wants an alarm to go off at 8am every day. Well you need to start thinking about timezones, since that "8am" needs to be local time.
If your software has business logic that cares about, say, what day a specific person perceived an event as happening, it needs to think about the timezone they have set.
So, in such cases, you'd better keep a history of all the timezones they've ever chosen, and the time (UTC) they changed them.
(Hopefully this lets someone else avoid my past mistakes.)