The article doesn't really go into why this is an issue, it just says that it's dangerous but doesn't deliver with explaining this danger. It goes even as far as saying that a time without timezone is worthless, but this is not my experience.

A good general rule of thumb is that for things that happened in the past, UTC is generally fine. You only need a timezone if there was some kind of locality to the event (e.g.: when _and_ where this happened), but usually you can convert to local time. So storing UTC time is fine, adding the timezone in rare cases.

For things that are scheduled in the future, usually you will want to store local time + a timezone identifier (in olsen format, not offsets), to guard against timezone/dst changes (yes they happen all the time)

There are exceptions to rule, but at least in my case 90% of the times I work with are timestamps in UTC and 9.99% things that happen in the future where I can apply the localtime + tz rule.

But yes there are exceptions:

* Alarm clocks (if you set an alarm at 8am, you typically don't want this to shift when you travel). This is called floating time * If you need records of when something was originally scheduled vs when it actually happened if a timezone change occurred. * If you need to handle the awkward DST time change where every time between 1 and 2am happen twice.