On 11/1/10 1:21 PM, Christopher Browne wrote:
> In my view, to use a timezone which has a known incontinuity (e.g. -
> where you can expect a 1 hour "leap" every so often) *is* the footgun.

For many organizations, by the time they realize that they have a timezone problem it has propagated
throughout their data center. They have databases, load balancers, network devices, etc. that all
have a notion of "time" in them, and reconciling those is a huge task.

Any timezone that has the concept of daylight savings time has one "missing" hour and one
"duplicated" hour every year. It is subject to "political" changes (e.g., changing the begin/end of
DST a few years ago in the US). If you have machines in multiple time zones, and, even worse, in
multiple time zone "regimes" (such that they can change at different times), you WILL have bizarre
effects where your log files are borked up or you have apparent discontinuities in your metrics.

I think that everyone should run everything in their data centers on UTC, and only "localize" the
time when necessary to deal with "outside" users. It makes sense that you schedule things like
machine downtime for convenient times for the majority of users (rather than "midnight UTC"), but
that doesn't stop you from expressing those schedules in UTC.

If you do this on day 1 of your enterprise (no matter how small) you will save yourself large
amounts of grief as you grow.

I know that several large internet companies haven't unified on UTC (because of the mass of things
that would have to change) and just expect problems at least twice a year as a result.

Michael