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 _______________________________________________ Slony1-general mailing list [email protected] http://lists.slony.info/mailman/listinfo/slony1-general
