<div dir="ltr">I favor retaining the region codes, which are useful, and eliminating the endless discussions by following ISO 3166 exactly, no deviations, no discussion.<div><br></div><div style> </div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, May 21, 2013 at 9:38 AM, Paul Eggert <span dir="ltr"><<a href="mailto:eggert@cs.ucla.edu" target="_blank">eggert@cs.ucla.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 05/21/13 09:18, Paul_Koning@Dell.com wrote:<br>
> by this argument you might have merged the entry for Venezuela with other<br>
> South American entries a few years ago -- but then the administration<br>
> there decided to do something different.<br>
<br>
</div>I think this would still work without user problems.<br>
Suppose in 2000 we had merged America/Caracas, America/Aruba,<br>
America/Curacao, and America/Port_of_Spain. These<br>
zones would have continued to work as before, because there<br>
would be 'backward' entries. Then, in 2007, when Venezuela<br>
decided to move its clocks, we would have split<br>
the America/Caracas zone into two regions,<br>
America/Caracas and (say) America/Curacao,<br>
and all the old names would still continue to work.<br>
Splitting zones is a normal part of time zone<br>
maintenance, and this sort of thing should be routine.<br>
<br>
It's true that keeping these zones distinct<br>
insulates users from plausible future political changes --<br>
but the downside is that there are zillions of plausible<br>
future political changes, and once we get into the<br>
business of guessing which changes are plausible enough to<br>
deserve a separate entry in the tz database, we are getting<br>
into the business of politics, which is an area we're<br>
better off avoiding.<br>
</blockquote></div><br></div>