The time zone for China should default to Beijing not Shanghai (when offline)

Bug #892370 reported by Kent Baxley on 2011-11-18
62
This bug affects 9 people
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://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/228554
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/517621

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.11.10
ProcVersionSignature: Ubuntu 3.0.0-12.20-generic 3.0.4
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

lp:~jm-leddy/timezonemap/clickanywhere
Timezone Map Team: Pending requested 2013-01-18
lp:~xnox/timezonemap/maps-places-and-things
Timezone Map Team: Pending requested 2013-03-27
lp:~xnox/indicator-datetime/clickanywhere
Mathieu Trudel-Lapierre: Disapprove on 2013-04-01
PS Jenkins bot: Approve (continuous-integration) on 2013-03-28
Mathieu Trudel-Lapierre: Needs Fixing on 2013-03-29
PS Jenkins bot: Approve (continuous-integration) on 2013-03-28
lp:~jm-leddy/ubiquity/clickanywhere
Rejected for merging into lp:ubiquity
Dimitri John Ledkov: Needs Fixing on 2013-04-05
Kent Baxley (kentb) wrote :
description: updated
Kent Baxley (kentb) on 2011-11-18
summary: - The time zone for China should be Beijing not Shanghai
+ The time zone for China default to Beijing not Shanghai
Kent Baxley (kentb) on 2011-11-18
summary: - The time zone for China default to Beijing not Shanghai
+ The time zone for China should default to Beijing not Shanghai
Kent Baxley (kentb) on 2011-11-18
Changed in oem-priority:
importance: Undecided → Medium
Kent Baxley (kentb) on 2011-11-18
Changed in oem-priority:
importance: Medium → High

Set oem-priority priority to medium to match other l10n-related priorities

Changed in oem-priority:
importance: High → Medium

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 :

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-center, where all of the major cities are being recognized and shown. This could re-use the data from libgweather (/usr/share/libgweather/Locations.xml) which also provides a nice type-ahead capability for searching your city.

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 :

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 :

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://www.23hq.com/Vincentt/photo/2589714
https://bugs.launchpad.net/ubuntu/+source/libgweather/+bug/228554/comments/18
https://en.wikipedia.org/wiki/Central_Plain_%28China%29

James M. Leddy (jm-leddy) wrote :

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://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/228554/+attachment/2183899/+files/Screenshot-13.png

Steve Langasek (vorlon) wrote :

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 :

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 :

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)
Jason Schuh (jschuh11) on 2012-03-14
Changed in ubiquity (Ubuntu):
status: New → Opinion
Changed in ubiquity (Ubuntu):
status: Opinion → New
tags: added: rls-q-incomming
Colin Watson (cjwatson) on 2012-06-26
tags: added: rls-q-incoming
removed: rls-q-incomming
Steve Langasek (vorlon) on 2012-06-26
tags: removed: rls-q-incoming
Colin Watson (cjwatson) wrote :

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 :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ubiquity (Ubuntu):
status: New → Confirmed
James M. Leddy (jm-leddy) wrote :

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 :

http://mm.icann.org/pipermail/tz/2012-August/018194.html

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://mm.icann.org/pipermail/tz/2012-August/018206.html
http://mm.icann.org/pipermail/tz/2012-August/018203.html

James M. Leddy (jm-leddy) wrote :

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 :

For precise users, I have a ppa here: https://launchpad.net/~jm-leddy/+archive/clickanywhere

Dimitri John Ledkov (xnox) wrote :

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 :

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.

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-lookup.ubuntu.com, after getting
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 :

> The way the code works in geonames-lookup.ubuntu.com, after getting
> 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 :
Dimitri John Ledkov (xnox) wrote :

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 :

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://bugs.launchpad.net/ubuntu/+source/libtimezonemap/+bug/905754/comments/11

Dimitri John Ledkov (xnox) wrote :

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 :

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 :

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 :

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 :

This does work with 'gnome-control-center indictator-datetime' though

Changed in oem-priority:
status: Won't Fix → In Progress
James M. Leddy (jm-leddy) wrote :

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-center. The changes that were made to gnome-control-center to work with the new libtimezonemap have to be changed in ubiquity as well.

Dimitri John Ledkov (xnox) wrote :

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 :

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 :

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.

http://uiobservatory.com/2010/what-time-is-your-zone/

Changed in indicator-datetime (Ubuntu Raring):
status: In Progress → Won't Fix
James M. Leddy (jm-leddy) wrote :

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-center.

Dimitri John Ledkov (xnox) wrote :

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 :

Some more details on the segfault:

Program received signal SIGSEGV, Segmentation fault.
0x00007fffe48d0c2e in get_loc_for_xy (widget=0x55555589e3c0, x=0, y=0)
    at /home/james/libtimezonemap-0.3.2+clickanywhere1/./src/cc-timezone-map.c:947
947 r = pixels[(rowstride * y + x * 4)];
(gdb) bt
#0 0x00007fffe48d0c2e in get_loc_for_xy (widget=0x55555589e3c0, x=0, y=0)
    at /home/james/libtimezonemap-0.3.2+clickanywhere1/./src/cc-timezone-map.c:947
#1 0x00007fffe48d17c8 in cc_timezone_map_set_location (map=0x55555589e3c0, lon=-77.366349999999997,
    lat=35.612659999999998) at /home/james/libtimezonemap-0.3.2+clickanywhere1/./src/cc-timezone-map.c:1177
#2 0x00007fffe4adf670 in ?? () from /usr/lib/control-center-1/panels/libindicator-datetime.so
#3 0x00007ffff64a3f97 in g_simple_async_result_complete (simple=0x555555b7e040)
    at /build/buildd/glib2.0-2.32.3/./gio/gsimpleasyncresult.c:767
#4 0x00007ffff64fc3dd in reply_cb (connection=<optimized out>, res=<optimized out>, user_data=0x555555b7e040)
    at /build/buildd/glib2.0-2.32.3/./gio/gdbusproxy.c:2614
#5 0x00007ffff64a3f97 in g_simple_async_result_complete (simple=0x555555b7e190)
    at /build/buildd/glib2.0-2.32.3/./gio/gsimpleasyncresult.c:767
#6 0x00007ffff64f27ba in g_dbus_connection_call_done (source=<optimized out>, result=<optimized out>,
    user_data=0x5555575b7cc0) at /build/buildd/glib2.0-2.32.3/./gio/gdbusconnection.c:5289
#7 0x00007ffff64a3f97 in g_simple_async_result_complete (simple=0x555556b6ed10)
    at /build/buildd/glib2.0-2.32.3/./gio/gsimpleasyncresult.c:767
#8 0x00007ffff64a4099 in complete_in_idle_cb (data=<optimized out>)
    at /build/buildd/glib2.0-2.32.3/./gio/gsimpleasyncresult.c:779
#9 0x00007ffff5f3ad53 in g_main_dispatch (context=0x55555577bc70)
    at /build/buildd/glib2.0-2.32.3/./glib/gmain.c:2539
#10 g_main_context_dispatch (context=0x55555577bc70) at /build/buildd/glib2.0-2.32.3/./glib/gmain.c:3075
#11 0x00007ffff5f3b0a0 in g_main_context_iterate (dispatch=1, block=<optimized out>, context=0x55555577bc70,
    self=<optimized out>) at /build/buildd/glib2.0-2.32.3/./glib/gmain.c:3146
#12 g_main_context_iterate (context=0x55555577bc70, block=<optimized out>, dispatch=1, self=<optimized out>)
    at /build/buildd/glib2.0-2.32.3/./glib/gmain.c:3083
#13 0x00007ffff5f3b164 in g_main_context_iteration (context=0x55555577bc70, may_block=1)
    at /build/buildd/glib2.0-2.32.3/./glib/gmain.c:3207
#14 0x00007ffff64cec94 in g_application_run (application=0x5555558a42b0, argc=<optimized out>,
    argv=0x7fffffffe1a8) at /build/buildd/glib2.0-2.32.3/./gio/gapplication.c:1507
#15 0x000055555555b7aa in main ()

Seems that if you run "Date and Time" from gnome-control-center you can get this to happen. It does not happen every time, but if you do it enough times it'll happen. The reason is "pixels" variable is uninitialized.

http://paste.ubuntu.com/5626791/

James M. Leddy (jm-leddy) wrote :

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_map_init() and either 1 or 2 calls to cc_timezone_map_size_allocate(). Using the packages from the repo, there is no problem. When using the "clickanywhere" binary, there are some instances when cc_timezon_map_init() is not called _at all_! So when this happens, we SIGSEV. I'm not exactly sure why this is happening. The functions referenced above are automatically called somewhere out of gtk or glib, and there isn't anything in the code that I've written to indicate that the glue code shouldn't have to call cc_timezone_map_init()

Note that this is only a problem when using gnome_control_center. If you use "Time & Date Settings..." directly from the time dropdown in the indicator, there's no problem.

Changed in ubuntukylin:
importance: Undecided → Wishlist
Ara Pulido (apulido) on 2014-02-11
Changed in oem-priority:
assignee: James M. Leddy (jm-leddy) → Ara Pulido (apulido)
tags: added: ubuntukylin
Ara Pulido (apulido) on 2014-05-05
Changed in oem-priority:
status: In Progress → Won't Fix
Rolf Leggewie (r0lf) wrote :

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
Rolf Leggewie (r0lf) on 2014-12-05
Changed in indicator-datetime (Ubuntu Saucy):
status: Confirmed → Won't Fix
Ubuntu QA Website (ubuntuqa) wrote :

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://iso.qa.ubuntu.com/qatracker/reports/bugs/892370

tags: added: iso-testing
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers