As there are two different timmezones being used in Xinjiang, China, would it be a good idea to create another timezone named something like Asia/Urumqi2 to correspond to the different timezone being used in the area?
> As there are two different timmezones being used in Xinjiang, China,
would it be a good idea to create another timezone named something like Asia/Urumqi2 to correspond to the different timezone being used in the area?
This matter has come up in the past; one approach floated in the past was to use the differing Anglicizations of translations from two languages used in the area. In the past, there was a claim that creating two zones would worsen a fraught political situation; there was no counter-claim, so no action was taken. The situation may well be different now, or the claims may be different; even if they're the same, the response may be different. @dashdashado On Wed, Apr 12, 2017 at 6:00 PM, gfb hjjhjh <c933103@gmail.com> wrote:
As there are two different timmezones being used in Xinjiang, China, would it be a good idea to create another timezone named something like Asia/Urumqi2 to correspond to the different timezone being used in the area?
On 12 April 2017 at 18:00, gfb hjjhjh <c933103@gmail.com> wrote:
As there are two different timmezones being used in Xinjiang, China, would it be a good idea to create another timezone named something like Asia/Urumqi2 to correspond to the different timezone being used in the area?
My understanding is that the two time zones in use in that region are the unofficial Xinjiang Time (UTC+6), which is represented in the database by Asia/Urumqi, and the official Beijing Time (UTC+8), which is represented by Asia/Shanghai. Are you aware of other time zones observed in this region that are not covered by one of these two rule sets? -- Tim Parenti
On 2017-04-12 16:00, gfb hjjhjh wrote:
As there are two different timmezones being used in Xinjiang, China, would it be a good idea to create another timezone named something like Asia/Urumqi2 to correspond to the different timezone being used in the area?
Time zones are named /after/ the most populous municipality in the area to which it applies, often but not always the capital: users in areas where different time zones may apply, may choose whichever of the alternatives applies to their uses of the time. See https://github.com/eggert/tz/blob/master/Theory Selecting time zone Asia/Shanghai gives Beijing time, and Asia/Urumqi Xinjiang time. Users in Xinjiang may choose whichever time zone suits them: government offices in the area mainly use Beijing time, others use Xinjiang time. Try the example time zone selection UI 'tzselect' provided with the package, select 4) Asia, 9) China, and you are offered the choices 1) Beijing Time, 2) Xinjiang Time. Both zones are associated with CN in tzdata zone.tab and zone1970.tab. If the UI or device you are using does not offer the choice, contact their support for workarounds or alternatives. For example, Windows 10 seems to support only: (UTC+08:00) Beijing, Chongqing, Hong Kong, Urumqi -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
But a problem with the current approach is that when some products opt to use geolocation-based timezone selection, users of UTC+8 timezone in the area that are not aware of the existence of UTC+6 timezone could be confused by why their gadgets would automatically get switched into UTC+6, as exampled by public reaction after one such iOS update. Ultimately that would make most manufacturer default the timezone for Xinjiang to UTC+8 instead since UTC+6-users are more aware of the situation and thus less likely to be confused. 2017-04-13 6:51 GMT+08:00 Brian Inglis <Brian.Inglis@systematicsw.ab.ca>:
On 2017-04-12 16:00, gfb hjjhjh wrote:
As there are two different timmezones being used in Xinjiang, China, would it be a good idea to create another timezone named something like Asia/Urumqi2 to correspond to the different timezone being used in the area?
Time zones are named /after/ the most populous municipality in the area to which it applies, often but not always the capital: users in areas where different time zones may apply, may choose whichever of the alternatives applies to their uses of the time.
See https://github.com/eggert/tz/blob/master/Theory
Selecting time zone Asia/Shanghai gives Beijing time, and Asia/Urumqi Xinjiang time. Users in Xinjiang may choose whichever time zone suits them: government offices in the area mainly use Beijing time, others use Xinjiang time.
Try the example time zone selection UI 'tzselect' provided with the package, select 4) Asia, 9) China, and you are offered the choices 1) Beijing Time, 2) Xinjiang Time. Both zones are associated with CN in tzdata zone.tab and zone1970.tab.
If the UI or device you are using does not offer the choice, contact their support for workarounds or alternatives.
For example, Windows 10 seems to support only: (UTC+08:00) Beijing, Chongqing, Hong Kong, Urumqi
-- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
gfb hjjhjh wrote:
But a problem with the current approach is that when some products opt to use geolocation-based timezone selection
I don't see how adding an alias would help resolve that problem. No matter what, manufacturers will need to decide what the default should be for people geographically located in Xinjiang. This is true regardless of whether the name of one zone is Asia/Shanghai or Asia/Urumqi2 or Asia/Whatever.
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, and those other UTC+6 towns could have could shift their time or change DST setting which make the option less than ideal as an substitute. 2017年4月13日 14:07 於 "Paul Eggert" <eggert@cs.ucla.edu> 寫道：
gfb hjjhjh wrote:
But a problem with the current approach is that when some products opt to use geolocation-based timezone selection
I don't see how adding an alias would help resolve that problem. No matter what, manufacturers will need to decide what the default should be for people geographically located in Xinjiang. This is true regardless of whether the name of one zone is Asia/Shanghai or Asia/Urumqi2 or Asia/Whatever.
Date: Thu, 13 Apr 2017 14:42:20 +0800 From: gfb hjjhjh <c933103@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
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@munnari.OZ.AU> wrote: Date: Thu, 13 Apr 2017 14:42:20 +0800 From: gfb hjjhjh <c933103@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
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@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@munnari.OZ.AU> wrote:
Date: Thu, 13 Apr 2017 14:42:20 +0800 From: gfb hjjhjh <c933103@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
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@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@munnari.OZ.AU> wrote:
Date: Thu, 13 Apr 2017 14:42:20 +0800 From: gfb hjjhjh <c933103@gmail.com> Message-ID: <CAGHjPPLow5kkwBmSTb=-P-M4W27P gd1VXzCZLfhA-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
On 2017-04-12 23:17, gfb hjjhjh wrote:
2017-04-13 6:51 GMT+08:00 Brian Inglis:
On 2017-04-12 16:00, gfb hjjhjh wrote:
As there are two different timmezones being used in Xinjiang, China, would it be a good idea to create another timezone named something like Asia/Urumqi2 to correspond to the different timezone being used in the area? If the UI or device you are using does not offer the choice, contact their support for workarounds or alternatives. But a problem with the current approach is that when some products opt to use geolocation-based timezone selection, users of UTC+8 timezone in the area that are not aware of the existence of UTC+6 timezone could be confused by why their gadgets would automatically get switched into UTC+6, as exampled by public reaction after one such iOS update. Ultimately that would make most manufacturer default the timezone for Xinjiang to UTC+8 instead since UTC+6-users are more aware of the situation and thus less likely to be confused.
That may be the correct decision for such situations. There are other time zone enclaves where the time zone usage varies depending on both location and whether an organization follows local or official time e.g. where the Navajo nation in Arizona, USA crosses state lines and observes DST as do adjacent states, but Arizona does not use DST, although national or federal offices in the state may observe DST if their headquarters or offices in nearby states also do so. It is up to third parties to decide how they use the time zone info provided. Making selections without allowing for *any* user input is probably not a wise approach. Workarounds or alternatives should be provided to correct inappropriate selections. You should contact those third parties if you disagree with their decisions. The provided tzselect script shows how it can be done easily and properly, and supports providing geolocation coordinates: see "man 8 tzselect" or run "tzselect --help" e.g. zone.tab gives the following location for Urumqi: CN +4348+08735 Asia/Urumqi Xinjiang Time and running "tzselect -c +4348+08735" displays the alternatives: Please identify a location so that time zone rules can be set correctly. Please select one of the following time zone regions, listed roughly in increasing order of distance from +4348+08735. 1) China - Xinjiang Time 2) Mongolia - Bayan-Ölgii, Govi-Altai, Hovd, Uvs, Zavkhan 3) Russia - MSK+04 - Kemerovo 4) Russia - MSK+04 - Altai 5) Russia - MSK+04 - Tomsk 6) Russia - MSK+04 - Novosibirsk 7) Kazakhstan - Kazakhstan (most areas) 8) Russia - MSK+04 - Krasnoyarsk area 9) Nepal 10) Bhutan Some third parties may not use this data or code, may choose to use only selected data or code, or not provide workarounds or alternatives for inappropriate selections. For example, satellite or cellular mobile phone service operators may only provide the time set on their towers or base stations, and handset platforms may be unable to provide alternatives. Time switching between zones is apparently fairly common when there are towers on both sides of nearby time zone boundaries. Options are sometimes provided to ignore "network" time and manually select the time (zone) to be displayed for this reason. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
On Apr 12, 2017, at 10:17 PM, gfb hjjhjh <c933103@gmail.com> wrote:
But a problem with the current approach is that when some products opt to use geolocation-based timezone selection, users of UTC+8 timezone in the area that are not aware of the existence of UTC+6 timezone could be confused by why their gadgets would automatically get switched into UTC+6, as exampled by public reaction after one such iOS update. Ultimately that would make most manufacturer default the timezone for Xinjiang to UTC+8 instead since UTC+6-users are more aware of the situation and thus less likely to be confused.
If a vendor opts to use geolocation-based timezone selection, then, at least as I understand the issue described here, they will need to handle Urumqi specially, because knowing the *location* is insufficient to know the *time zone offset and rules* - some people there use the standard Chinese rules and some people there use the Urumqi rules. That's (currently) outside the scope of the tzdb, as is providing shapefiles or whatever for the regions to which particular tzdb zones apply. Any such collection of shapefiles-and-zones should support having *more than one* zone for a region and, for the region to which Xinjiang belongs, provide both Asia/Shanghai and Asia/Urumqi. Any code using such a collection should do something appropriate, e.g. letting the user choose which one to use *and* remember that choice (so that, for example, if the user of some product has selected "Urumqi time", when a tzdb update is processed, the code doesn't switch to "regular China time"). If, with a tzdb update, iOS chose to remove /etc/localtime and link it to /usr/share/zoneinfo/Asia/Shanghai, even though it had been previously linked to /usr/share/zoneinfo/Asia/Urumqi, that's an iOS bug, and Apple should fix it. (And the same applies if they happen to have a separate mechanism for specifying the current time zone in ICU or Foundation.) It's not our problem and not our fault.
participants (9)
-
Arthur David Olson -
Brian Inglis -
Evan Siroky -
gfb hjjhjh -
Guy Harris -
Paul Eggert -
Robert Elz -
Steve Jones -
Tim Parenti