[jperras]

Author here.

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!

[aaravchen]

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.

[erik_seaberg]

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.

[treve]

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!