<div dir="ltr">The fundamental problem here is that there is no well-defined geographic boundary between the two regions — they inherently overlap, as two people standing in the same room could easily disagree on which zone they should use for that exact spot.<div><br></div><div>One group asserts that there is no boundary at all.  The other group acknowledges a disparity, but one that's not dependent so much on geography as it is on who exactly you're talking to within the affected region.</div><div><br></div><div>Unfortunately, no software that purports to try to decide this automatically will make the right decision for all users.  In cases like these, the only correct course of action is to explicitly ask each user which they prefer, but for many often-political reasons even that may not always be desirable.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature">--<br>Tim Parenti<br></div></div>
<br><div class="gmail_quote">On 13 April 2017 at 13:00, Evan Siroky via tz <span dir="ltr"><<a href="mailto:tz@iana.org" target="_blank">tz@iana.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="color:#000;background-color:#fff;font-family:Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div dir="ltr" id="m_-699562153496236160yui_3_16_0_ym19_1_1491811245271_247594">I'll put in a plug for my project timezone-boundary-builder (<a href="https://github.com/evansiroky/timezone-boundary-builder" target="_blank">https://github.com/<wbr>evansiroky/timezone-boundary-<wbr>builder</a>).  timezone-boundary-builder does attempt to exactly quantify the geographic boundaries of timezones in the timezone database.  Maybe it can help you design some software that chooses the right timezone.<br></div><div><div class="h5"> <div class="m_-699562153496236160qtdSeparateBR"><br><br></div><div class="m_-699562153496236160yahoo_quoted" style="display:block"> <div style="font-family:Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif;font-size:16px"> <div dir="ltr"><font size="2" face="Arial"> On Thursday, 13 April 2017, 2:22, Robert Elz <<a href="mailto:kre@munnari.OZ.AU" target="_blank">kre@munnari.OZ.AU</a>> wrote:<br></font></div>  <br><br> <div class="m_-699562153496236160y_msg_container"><div dir="ltr">    Date:        Thu, 13 Apr 2017 14:42:20 +0800<br clear="none">    From:        gfb hjjhjh <<a shape="rect" href="mailto:c933103@gmail.com" target="_blank">c933103@gmail.com</a>><br clear="none">    Message-ID:  <CAGHjPPLow5kkwBmSTb=<a shape="rect" href="mailto:-P-M4W27Pgd1VXzCZLfhA-PpMeumHWQ@mail.gmail.com" target="_blank">-P-<wbr>M4W27Pgd1VXzCZLfhA-PpMeumHWQ@<wbr>mail.gmail.com</a>><br clear="none"><br clear="none">  | Yeah, however in the current situation when manufacturer choose to default<br clear="none">  | the time in Xinjiang to UTC+8, UTC+6-users in the region can only pick for<br clear="none">  | example some Russian cities in their device to force their devices to use<br clear="none">  | UTC+6,<br clear="none"><br clear="none">Then you should complain to the maunfacturer (of the software, not necessarily<br clear="none">hardware, though you might need to go through the latter to get to the former)<br clear="none">about how things are shipped, and the defaults chosen.<br clear="none"><br clear="none">This project locates what timezones exist, and makes zones (in the database)<br clear="none">for each of them.  If a zone is missing from the tz database, or contains<br clear="none">incorrect (time/date) data (please don't complain about names...) then<br clear="none">we would love to receive corrections, particularly if supported by some kind<br clear="none">or verifiable evidence (but even rumors can be useful as a starting point.)<br clear="none"><br clear="none">Once the zones exist, users (either end users who install this themselves<br clear="none">or system manufactures/integrators) are free to apply them however, and in<br clear="none">whatever manner they like - we have neither control, nor even influence over<div class="m_-699562153496236160yqt5106828944" id="m_-699562153496236160yqtfd24284"><br clear="none">that.</div><br clear="none"><br clear="none">The closest we come is with tzselect (which some, including me, believe is<br clear="none">really outside the scope of this project, and shouldn't be included at all.)<br clear="none">But in this case, that should/would work for what you want, had the<br clear="none">manufacturer chosen to use it (but it is a fairly primitive interface, and<br clear="none">it is understandable why they would prefer something better.)<br clear="none"><br clear="none">Note: it is entirely possible that some manufacturers might choose not to<br clear="none">risk upsetting the Chinese authorities by admitting the existance of a<br clear="none">time zone in China that the authorities would prefer to believe does not exist.<br clear="none"><br clear="none">Again, there is nothing that we can do about that ... your only real<br clear="none">recourse (if a simple bug report to the manufacturer does not change things)<br clear="none">is for affected users to refuse to buy products from manufacturers who<br clear="none">refuse to support them properly, and hope that the economic consequences<br clear="none">will sway the manufacturer ... or to convince the authorities that having<br clear="none">a single time zone for all of China is not the best approach, so a policy<br clear="none">change could allow everyone to be happy.<br clear="none"><br clear="none">Again none of that is anything this project can assist with.<br clear="none"><br clear="none">kre<div class="m_-699562153496236160yqt5106828944" id="m_-699562153496236160yqtfd08873"><br clear="none"><br clear="none"></div></div><br><br></div>  </div> </div>  </div></div></div></div></div></blockquote></div><br></div>