[tz] Urumqi timezone.

[Steve Jones]

Even just trying to put accurate North American time zones into accurate
data format was a monumental task with many arbitrary judgements related to
disputes, unofficial deviations, and poorly documented factors.  I believe
OnTimeZone.com remains an accurate and authoritative source for that data,
but nothing can truly claim to be "correct".  There just is no such thing.

Steve Jones
[image: Emacs!]

On Thu, Apr 13, 2017 at 12:00 PM, 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-M4W27P
> gd1VXzCZLfhA-PpMeumHWQ at 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/a3251ed1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1a7ee1f.jpg
Type: image/jpeg
Size: 24577 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/tz/attachments/20170413/a3251ed1/1a7ee1f-0001.jpg>