While it's decent advice, I don't think the reasoning here is particularly helpful.
> DST is different in different timezones, and at some points the overlap will cause a bug when interacting with other systems
That's mostly just an argument for using the same timezone in all of your systems.
> I have (in the past), seen servers where the system timezone is set to PST, but the database is set to UTC
Same deal.
> There are thousands of bugs out there that are caused by timezones
A google search for any other word + bug is going to give you plenty of hits too.
> UTC assuming code interacting with non UTC assuming code can, and has caused silent data corruption
This is an argument for non-naive datetimes. Also is the same regardless of the two timezones involved.
> migrating later than the start of the infrastructure can be really painful, because of your app getting coupled to the timezone itβs in.
That's an argument for not changing timezones, rather than using UTC.
The other couple arguments are similarly moot.
While UTC is good, I think the key is really using consistent date handling. The most important bit is how you store them in the database, and in that regard I'm a fan of fully-non-ambiguous storage. That means either unix timestamps, or timezone-aware datetimes. Ambiguity by assuming a datetime everywhere from a data perspective is where you'll create confusion.
> > DST is different in different timezones, and at some points the overlap will cause a bug when interacting with other systems
> That's mostly just an argument for using the same timezone in all of your systems.
The TZ database is not static. Governments have a habit of monkeying with DST definitions to suit their whims. Several of your systems may have TZ updates come out at different times. Debian/java/erlang/windows have different rollouts for the TZ database that you have to coordinate somehow if you want all your systems to agree on the time/date.
> DST is different in different timezones, and at some points the overlap will cause a bug when interacting with other systems
That's mostly just an argument for using the same timezone in all of your systems.
> I have (in the past), seen servers where the system timezone is set to PST, but the database is set to UTC
Same deal.
> There are thousands of bugs out there that are caused by timezones
A google search for any other word + bug is going to give you plenty of hits too.
> UTC assuming code interacting with non UTC assuming code can, and has caused silent data corruption
This is an argument for non-naive datetimes. Also is the same regardless of the two timezones involved.
> migrating later than the start of the infrastructure can be really painful, because of your app getting coupled to the timezone itβs in.
That's an argument for not changing timezones, rather than using UTC.
The other couple arguments are similarly moot.
While UTC is good, I think the key is really using consistent date handling. The most important bit is how you store them in the database, and in that regard I'm a fan of fully-non-ambiguous storage. That means either unix timestamps, or timezone-aware datetimes. Ambiguity by assuming a datetime everywhere from a data perspective is where you'll create confusion.