The time zone for China should default to Beijing not Shanghai (when offline)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Indicator Date and Time |
New
|
Undecided
|
Unassigned | ||
OEM Priority Project |
Medium
|
Ara Pulido | |||
Oneiric |
Medium
|
Unassigned | |||
Precise |
Medium
|
Unassigned | |||
Quantal |
Medium
|
Unassigned | |||
Raring |
Medium
|
Unassigned | |||
Ubuntu Kylin |
Wishlist
|
Unassigned | |||
indicator-datetime (Ubuntu) |
Wishlist
|
Unassigned | |||
Quantal |
Undecided
|
Unassigned | |||
Raring |
Wishlist
|
Unassigned | |||
Saucy |
Undecided
|
Unassigned | |||
libtimezonemap (Ubuntu) |
Wishlist
|
Unassigned | |||
Quantal |
Undecided
|
Unassigned | |||
Raring |
Wishlist
|
Unassigned | |||
Saucy |
Undecided
|
Unassigned | |||
ubiquity (Ubuntu) |
High
|
Canonical Foundations Team | |||
Quantal |
High
|
Canonical Foundations Team | |||
Raring |
High
|
Canonical Foundations Team | |||
Saucy |
High
|
Canonical Foundations Team |
Bug Description
When installing Ubuntu and selecting Simplified Chinese as the default language, the default timezone should point to Beijing instead of Shanghai. Everything in China is referenced to Beijing time. In mainland China this standard time is called Beijing Time (北京时间) domestically but it is commonly referred to as China Standard Time (CST) internationally.
This seems to have come up a lot in past bugs:
https:/
https:/
Steps to recreate:
1) Install Ubuntu and select Simplified Chinese for the language.
Actual Results:
At the timezone page, the default city is Shanghai.
Expected Results:
Most Chinese users prefer it be set to Beijing.
It looks as if the upstream tz database needs to be updated for Beijing for starters, as Beijing is not listed in there.
ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: tzdata 2011n-0ubuntu0.
ProcVersionSign
Uname: Linux 3.0.0-12-generic x86_64
ApportVersion: 1.23-0ubuntu4
Architecture: amd64
Date: Fri Nov 18 15:26:03 2011
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
SourcePackage: tzdata
UpgradeStatus: No upgrade log present (probably fresh install)
Related branches
- Timezone Map Team: Pending requested 2013-01-18
-
Diff: 22959 lines (+22735/-29)9 files modifiedINSTALL (+7/-2)
debian/changelog (+14/-0)
src/Makefile.am (+2/-1)
src/cc-timezone-map.c (+13/-0)
src/cc-timezone-map.h (+2/-0)
src/data/cities15000.txt (+22644/-0)
src/timezone-completion.c (+16/-13)
src/tz.c (+36/-12)
src/tz.h (+1/-1)
- Timezone Map Team: Pending requested 2013-03-27
-
Diff: 25012 lines (+24756/-31)12 files modifiedINSTALL (+7/-2)
TODO (+2/-0)
debian/changelog (+15/-0)
debian/control (+1/-1)
src/Makefile.am (+4/-2)
src/cc-timezone-map.c (+13/-0)
src/cc-timezone-map.h (+2/-0)
src/data/cities15000.txt (+22644/-0)
src/data/time_zones_countryInfo-orig.svg (+2015/-0)
src/timezone-completion.c (+16/-13)
src/tz.c (+36/-12)
src/tz.h (+1/-1)
- Mathieu Trudel-Lapierre: Disapprove on 2013-04-01
- PS Jenkins bot: Approve (continuous-integration) on 2013-03-28
-
Diff: 146 lines (+56/-6) (has conflicts)4 files modifieddata/com.canonical.indicator.datetime.gschema.xml (+14/-0)
debian/changelog (+4/-0)
src/datetime-prefs.c (+36/-6)
src/settings-shared.h (+2/-0)
- Mathieu Trudel-Lapierre: Needs Fixing on 2013-03-29
- PS Jenkins bot: Approve (continuous-integration) on 2013-03-28
-
Diff: 399 lines (+111/-94)7 files modifieddata/com.canonical.indicator.datetime.gschema.xml (+14/-0)
data/datetime-dialog.ui (+1/-1)
debian/changelog (+7/-0)
debian/control (+2/-0)
src/datetime-prefs.c (+79/-87)
src/datetime-service.c (+6/-6)
src/settings-shared.h (+2/-0)
- Dimitri John Ledkov: Needs Fixing on 2013-04-05
-
Diff: 94 lines (+20/-18) (has conflicts)3 files modifieddebian/changelog (+9/-0)
ubiquity/plugins/ubi-timezone.py (+5/-5)
ubiquity/tz.py (+6/-13)
summary: |
- The time zone for China should be Beijing not Shanghai + The time zone for China default to Beijing not Shanghai |
summary: |
- The time zone for China default to Beijing not Shanghai + The time zone for China should default to Beijing not Shanghai |
Changed in oem-priority: | |
importance: | Undecided → Medium |
Changed in oem-priority: | |
importance: | Medium → High |
Steve Magoun (smagoun) wrote : Re: The time zone for China should default to Beijing not Shanghai | #2 |
Changed in oem-priority: | |
importance: | High → Medium |
Rick Spencer (rick-rickspencer3) wrote : | #4 |
Could you please investigate fixing this?
Changed in tzdata (Ubuntu): | |
importance: | Undecided → High |
assignee: | nobody → Canonical Desktop Team (canonical-desktop-team) |
Martin Pitt (pitti) wrote : | #5 |
We really don't want a permanent diversion from upstream tzdata; maintaining this database is quite a huge task, and introducing a delta will only make us slower to respond to updates and introduce more margin for error. More importantly, we'll make Ubuntu installations (/etc/timezone) incompatible with all other systems out there which use tzdata (which is "everything but Windows").
What seems more realistic is to extend the time zone picker to behave more like the one from gnome-control-
affects: | tzdata (Ubuntu) → ubiquity (Ubuntu) |
Changed in ubiquity (Ubuntu): | |
assignee: | Canonical Desktop Team (canonical-desktop-team) → nobody |
Changed in ubiquity (Ubuntu): | |
assignee: | nobody → Canonical Foundations Team (canonical-foundations) |
Steve Langasek (vorlon) wrote : | #6 |
I think there might be two appropriate changes here:
- update the ubiquity tz picker to highlight Beijing instead of Shanghai on the map when selecting this timezone
- update the Chinese translation of tzdata to name Beijing, even though the upstream zoneinfo entry is called Asia/Shanghai
James M. Leddy (jm-leddy) wrote : | #7 |
Hi Steve,
Since ubiquity gets the data from zone.tab, you can't do #1 without modifying the tzdata package from upstream, which is something that Ubuntu developers have specified multiple times that they are not willing to do. As such, #2 would be confusing and we would have the same situation as in comment #18 of bug #228554:
> The name is Beijing, but the location is Shanghai. It's very very funny.
Easiest fix would be to change the Chinese translation of tzdata to name "Zhongyuan Time ('Central plain Time')". That way Chinese users would not be _as_ confused because Shanghai is within "Zhongyuan Time". It would be like the dialog selecting "Eastern Time" but putting a dot on New York.
http://
https:/
https:/
James M. Leddy (jm-leddy) wrote : | #8 |
Also, it is not clear that the work in translating cities in zone.tab has been done yet. Here is a screenshot from June of this year: https:/
Steve Langasek (vorlon) wrote : | #9 |
Ah, I didn't realize the coordinates data came from the zone.tab file. Still, patching tzdata for a coordinate change is a much smaller delta from upstream than changing the timezone name, and might be something we'd be able to carry. But changing just the zone translation as you suggest to be city neutral also seems a reasonable compromise.
James M. Leddy (jm-leddy) wrote : | #10 |
Hi Steve,
I recommend that we carry the patch in bug 228554. It's only three additional lines, and we carry much larger patches for eg. java in the tzdata package, and it does this without changing the name of the time zone at all.
Martin Pitt (pitti) wrote : | #11 |
Please note that this only affects the offline case. When you are online, both ubiquity and the time selector in the control center/indicator use the GeoIP database which has all major cities in the world.
summary: |
- The time zone for China should default to Beijing not Shanghai + The time zone for China should default to Beijing not Shanghai (when + offline) |
Changed in ubiquity (Ubuntu): | |
status: | New → Opinion |
Changed in ubiquity (Ubuntu): | |
status: | Opinion → New |
tags: | added: rls-q-incomming |
tags: |
added: rls-q-incoming removed: rls-q-incomming |
tags: | removed: rls-q-incoming |
Colin Watson (cjwatson) wrote : | #12 |
James, do you think you could send that tzdata patch to the upstream mailing list? That would be the fastest way to move this forward; it would remove the question of Ubuntu carrying a delta, and we pull in new upstream releases pretty frequently.
Launchpad Janitor (janitor) wrote : | #13 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in ubiquity (Ubuntu): | |
status: | New → Confirmed |
James M. Leddy (jm-leddy) wrote : | #14 |
Hi Colin, I'll do that, but they have a history of rejecting that change.
I was thinking in case they do reject it we can keep a local list of the cities150000.txt in libmap so that we don't have different functionality while we're offline than we do while we're online. I already have the patch to libmap, but I need to modify indicator-date-time as well. I'll post here once I have it.
James M. Leddy (jm-leddy) wrote : | #15 |
http://
No one seems too eager to take the change. However, I did gain valuable insight into how OS X does it. Apparantly, they have a local copy of cities15000.txt, and then use the search bar to look through those cities. So basically the same thing we do when you're connected online. Additionally, the OS X picker allows you to drag the cursor to any one of these cities.
http://
http://
James M. Leddy (jm-leddy) wrote : | #16 |
The two branches attached to this should produce a binary that lets you choose beijing for the city, even when offline. I have not tested the quantal branch of indicator-datetime personally because of a lack of time, but the patch was clean and it compiled so I'm assuming it's good.
James M. Leddy (jm-leddy) wrote : | #17 |
For precise users, I have a ppa here: https:/
Dimitri John Ledkov (xnox) wrote : | #18 |
I have tested the packages in clickanywhere. They are defiantly much better.
But there are further changes required on ubiquity side?
As the auto-completion is off in ubiquity in the offline mode and clicking with the mouse gives me many locations now, but not beijing.
On the packaging side the list of cities should be in arch:all package instead of inside arch:any.
ps. I am from Latvia and it is ten times smaller than Beijing. Yet Riga,Latvia is in zone.tab and hence in ubiquity/offline, yet Beijing isn't.
James M. Leddy (jm-leddy) wrote : | #19 |
Hi,
Thanks much for testing. I've been meaning to test on the ubiquity side of things, but I haven't been able to build an image with those packages yet. I'm not sure if they're using a different package or what's going on. Every time I have tested in a running install offline I was able to select Beijing. However, clicking on a given city is pretty tough to do, since there are a lot of locations in geonames. The trick is to continue clicking without using the mouse. When this is done the pin will radiate outwards from where you initially clicked, always going to the next closest city.
I'll investigate more and also fix the problem on the packaging side of things.
Dimitri John Ledkov (xnox) wrote : Re: [Bug 892370] Re: The time zone for China should default to Beijing not Shanghai (when offline) | #20 |
On 28 September 2012 22:09, James M. Leddy <email address hidden> wrote:
> Hi,
>
> Thanks much for testing. I've been meaning to test on the ubiquity side
> of things, but I haven't been able to build an image with those packages
> yet. I'm not sure if they're using a different package or what's going
> on. Every time I have tested in a running install offline I was able to
> select Beijing. However, clicking on a given city is pretty tough to do,
> since there are a lot of locations in geonames. The trick is to continue
> clicking without using the mouse. When this is done the pin will radiate
> outwards from where you initially clicked, always going to the next
> closest city.
>
> I'll investigate more and also fix the problem on the packaging side of
> things.
>
The way the code works in geonames-
the mouse cursor, we take the area around it (not sure how big), get
the list of cities sorted by population & take the top onces. Because
most likely you want a 20 M Bejing and not the 15k population location
next to it.
It's actually very each to test LiveCD, start live session add your
ppa, upgrade packages (even ubiquity itself) and run it for fun and
profit. Not need to rebuild the images ;-)
Regards,
Dmitrijs.
James M. Leddy (jm-leddy) wrote : | #21 |
> The way the code works in geonames-
> the mouse cursor, we take the area around it (not sure how big), get
> the list of cities sorted by population & take the top onces. Because
> most likely you want a 20 M Bejing and not the 15k population location
> next to it.
I see, I can build that functionality in to the next version. I wasn't aware that the population factored in to it.
Dimitri John Ledkov (xnox) wrote : | #22 |
The http://
Note the: client.
Dimitri John Ledkov (xnox) wrote : | #23 |
The "small" fix in tzdata was not accepted. The better fix with cached cities & improved geo-picker still needs further work. Targeting this to r-series for now.
Changed in ubiquity (Ubuntu Quantal): | |
status: | Confirmed → Won't Fix |
James M. Leddy (jm-leddy) wrote : | #24 |
Hi Dmitrijs,
I've looked into it, but I think population weighing comes into play when you type in the name of the town. When clicking on the map, the behavior is to go to the town next nearest what you clicked.
https:/
Dimitri John Ledkov (xnox) wrote : | #25 |
Dear James,
Interesting, thanks for investigating this. So where were we left last cycle?
Upload / sponsor:
lp:~jm-leddy/ubuntu/quantal/timezonemap/clickanywhere
lp:~jm-leddy/ubuntu/quantal/indicator-datetime/clickanywhere
And then port ubiquity as well? Or ubiquity doesn't need any porting as long as above is on the images?
James M. Leddy (jm-leddy) wrote : | #26 |
I have to talk with cjwatson about ubiquity. I would assume that ubiquity would just link to the new indicator-datetime but it may be a re-implementation so I would like to be sure. I'll update this bug once I have that informatoin.
Tomofumi (tomofumi) wrote : | #27 |
I just come across this problem when i install Xubuntu 12.04.1, in "where are you" screen, I repeatedly click the China map, and it keeps showing Chongqing or Shanghai but no Beijing. This is a really odd user experience. Maybe they should change the question as "Choose your closest location" or something like that rather than asking for exact place.
Changed in oem-priority: | |
status: | In Progress → Won't Fix |
James M. Leddy (jm-leddy) wrote : | #28 |
I just tried this in the install environment and it does not work. There are probably changes to ubiquity that need to happen.
James M. Leddy (jm-leddy) wrote : | #29 |
This does work with 'gnome-
Changed in oem-priority: | |
status: | Won't Fix → In Progress |
James M. Leddy (jm-leddy) wrote : | #30 |
I've been looking through the ubiquity code, and it turns out they re-implement in python a bunch of things that are in gnome-control-
Dimitri John Ledkov (xnox) wrote : | #31 |
I've rebuild libtimezonemap & indicator-datetime (had to tweak a little) the code itself is fine.
But, I managed to select Scarborough, Leicester and Kettering but not London. Similarly with Beijing, I managed to click many more new cities but not Beijing.
Currently we cycle all timzeone cities in the 10x10 pixel area around the point clicked.
Maybe with offline cache we should cycle the cities by size starting with largest city in the 10x10 pixel area?!
Changed in libtimezonemap (Ubuntu Quantal): | |
status: | New → Won't Fix |
Changed in libtimezonemap (Ubuntu Raring): | |
importance: | Undecided → Wishlist |
status: | New → In Progress |
Launchpad Janitor (janitor) wrote : | #32 |
This bug was fixed in the package libtimezonemap - 0.4.0
---------------
libtimezonemap (0.4.0) raring; urgency=low
[ James M Leddy ]
* Simplfy setting location
* Use latitude/longitude for local cities as well (LP: #892370)
* Add m4 directory to prevent aclocal from complaining.
* Include cities with greater than 15000 people locally.
[ Dmitrijs Ledkovs ]
* Add original timezone svg map, thanks to Otto for finding it.
* Bump standards version to 3.9.4.
* Fix gir scanner options.
-- Dmitrijs Ledkovs <email address hidden> Thu, 28 Mar 2013 11:23:23 +0000
Changed in libtimezonemap (Ubuntu Raring): | |
status: | In Progress → Fix Released |
Changed in indicator-datetime (Ubuntu Quantal): | |
status: | New → Won't Fix |
Changed in indicator-datetime (Ubuntu Raring): | |
status: | New → In Progress |
importance: | Undecided → Wishlist |
James M. Leddy (jm-leddy) wrote : | #33 |
The tzdata mailing list pointed me to the Mac implementation. I don't know if they managed to avoid the problem of cities being too close in a 10x10px area. They are using geonames as well, and the smallest city data-set is cities where population > 15000, which we're already using.
Changed in indicator-datetime (Ubuntu Raring): | |
status: | In Progress → Won't Fix |
James M. Leddy (jm-leddy) wrote : | #34 |
I think it needs a bit more work. I've encountered a segfault when you are connected to the internet and you change the time through gnome-control-
Dimitri John Ledkov (xnox) wrote : | #35 |
Based on comment #34 unfortunately moving this to s-series.
Changed in ubiquity (Ubuntu Raring): | |
status: | Confirmed → Won't Fix |
James M. Leddy (jm-leddy) wrote : | #36 |
Some more details on the segfault:
Program received signal SIGSEGV, Segmentation fault.
0x00007fffe48d0c2e in get_loc_for_xy (widget=
at /home/james/
947 r = pixels[(rowstride * y + x * 4)];
(gdb) bt
#0 0x00007fffe48d0c2e in get_loc_for_xy (widget=
at /home/james/
#1 0x00007fffe48d17c8 in cc_timezone_
lat=
#2 0x00007fffe4adf670 in ?? () from /usr/lib/
#3 0x00007ffff64a3f97 in g_simple_
at /build/
#4 0x00007ffff64fc3dd in reply_cb (connection=
at /build/
#5 0x00007ffff64a3f97 in g_simple_
at /build/
#6 0x00007ffff64f27ba in g_dbus_
user_
#7 0x00007ffff64a3f97 in g_simple_
at /build/
#8 0x00007ffff64a4099 in complete_in_idle_cb (data=<optimized out>)
at /build/
#9 0x00007ffff5f3ad53 in g_main_dispatch (context=
at /build/
#10 g_main_
#11 0x00007ffff5f3b0a0 in g_main_
self=<optimized out>) at /build/
#12 g_main_
at /build/
#13 0x00007ffff5f3b164 in g_main_
at /build/
#14 0x00007ffff64cec94 in g_application_run (application=
argv=
#15 0x000055555555b7aa in main ()
Seems that if you run "Date and Time" from gnome-control-
James M. Leddy (jm-leddy) wrote : | #37 |
I've figured out the immediate root cause, though I'm still puzzled why the new "clickanywhere" code causes the problem. The initialization path for the widget takes it through the function calls cc_timezone_
Note that this is only a problem when using gnome_control_
Changed in ubuntukylin: | |
importance: | Undecided → Wishlist |
Changed in oem-priority: | |
assignee: | James M. Leddy (jm-leddy) → Ara Pulido (apulido) |
tags: | added: ubuntukylin |
Changed in oem-priority: | |
status: | In Progress → Won't Fix |
Rolf Leggewie (r0lf) wrote : | #38 |
saucy has seen the end of its life and is no longer receiving any updates. Marking the saucy task for this ticket as "Won't Fix".
Changed in ubiquity (Ubuntu Saucy): | |
status: | Confirmed → Won't Fix |
Changed in indicator-datetime (Ubuntu Saucy): | |
status: | Confirmed → Won't Fix |
Ubuntu QA Website (ubuntuqa) wrote : | #40 |
This bug has been reported on the Ubuntu ISO testing tracker.
A list of all reports related to this bug can be found here:
http://
tags: | added: iso-testing |
Set oem-priority priority to medium to match other l10n-related priorities