[tz] Urumqi timezone.

Tim Parenti tim at timtimeonline.com
Thu Apr 13 17:07:19 UTC 2017


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.

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.

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.

--
Tim Parenti

On 13 April 2017 at 13:00, Evan Siroky via tz <tz at iana.org> wrote:

> I'll put in a plug for my project timezone-boundary-builder (
> https://github.com/evansiroky/timezone-boundary-builder).
>  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.
>
>
> On Thursday, 13 April 2017, 2:22, Robert Elz <kre at munnari.OZ.AU> wrote:
>
>
>     Date:        Thu, 13 Apr 2017 14:42:20 +0800
>     From:        gfb hjjhjh <c933103 at gmail.com>
>     Message-ID:  <CAGHjPPLow5kkwBmSTb=-P-M4W27Pgd1VXzCZLfhA-PpMeumHWQ@
> mail.gmail.com>
>
>   | Yeah, however in the current situation when manufacturer choose to
> default
>   | the time in Xinjiang to UTC+8, UTC+6-users in the region can only pick
> for
>   | example some Russian cities in their device to force their devices to
> use
>   | UTC+6,
>
> Then you should complain to the maunfacturer (of the software, not
> necessarily
> hardware, though you might need to go through the latter to get to the
> former)
> about how things are shipped, and the defaults chosen.
>
> This project locates what timezones exist, and makes zones (in the
> database)
> for each of them.  If a zone is missing from the tz database, or contains
> incorrect (time/date) data (please don't complain about names...) then
> we would love to receive corrections, particularly if supported by some
> kind
> or verifiable evidence (but even rumors can be useful as a starting point.)
>
> Once the zones exist, users (either end users who install this themselves
> or system manufactures/integrators) are free to apply them however, and in
> whatever manner they like - we have neither control, nor even influence
> over
>
> that.
>
>
> The closest we come is with tzselect (which some, including me, believe is
> really outside the scope of this project, and shouldn't be included at
> all.)
> But in this case, that should/would work for what you want, had the
> manufacturer chosen to use it (but it is a fairly primitive interface, and
> it is understandable why they would prefer something better.)
>
> Note: it is entirely possible that some manufacturers might choose not to
> risk upsetting the Chinese authorities by admitting the existance of a
> time zone in China that the authorities would prefer to believe does not
> exist.
>
> Again, there is nothing that we can do about that ... your only real
> recourse (if a simple bug report to the manufacturer does not change
> things)
> is for affected users to refuse to buy products from manufacturers who
> refuse to support them properly, and hope that the economic consequences
> will sway the manufacturer ... or to convince the authorities that having
> a single time zone for all of China is not the best approach, so a policy
> change could allow everyone to be happy.
>
> Again none of that is anything this project can assist with.
>
> kre
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20170413/a1103824/attachment.html>


More information about the tz mailing list