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.
I admit that I didn't fully explain the danger, because I thought it was somewhat self-evident: if you attempt to compare two datetimes correctly, you must know their timezones. Anyone who has used Google Calendar to schedule a meeting in SF when they live in NYC can attest to that.
> 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.
We're both saying the same thing, here.
While UTC is not _technically_ a timezone, most databases/programming languages/etc. let you attach UTC to a datetime. When you say that you're "storing UTC time", you are implicitly storing it with enough information.
The difference is that I don't like the implicit nature of assuming a timezone-naive datetime is UTC, because that is a very dangerous assumption to make. Just store the timezone, even if it's UTC!
It's a pretty solid sign of an inexperienced developer when they think UTC needs to always be listed as the timezone. Most people with more experience know that if there's no timezone attached it should always be populated in, and assumed to already be in, UTC.
That said, it's rarely mentioned, which is a problem. And as the parent comment mentions, there are valid cases for tracking things in local timezones to retain user-local consistency.
There's a long history of databases using a client-controlled timezone per connection (which defaults to the server's local timezone) and storing only local time. I wouldn't rely on seeing UTC unless the team is very careful about migrating legacy data and consistently using TIMESTAMP WITH TIME ZONE columns and functions.
I think on the first read I didn't get that your article was basically about 'floating times', which upon a second read I totally agree is a weird default and good to avoid!
No, because countries update their DST rules all the time so you don't know for certain which UTC time corresponds with 'wall clock time'. So if we agree on a 1pm meeting in Sao Paolo, it might not be clear yet until later what UTC time that is.
I do not like that Python does not allow tz-naive time to be interpreted as UTC, which does not need a timezone. So you have to waste space by using a tz-aware format or you have to add the TZ +00 manually in some way.
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.