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

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

http://thread.gmane.org/gmane.comp.time.tz/3819

Could you please investigate fixing this?

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.

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

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

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

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.

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.

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.

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.

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

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.

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

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.

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

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.

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.

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

The http://geoname-lookup.ubuntu.com code is here http://bazaar.launchpad.net/~ubuntu-geonames-hackers/ubuntu-geonames/trunk/view/head:/geoname-modpython.py

Note the: client.SetSortMode(sphinxapi.SPH_SORT_ATTR_DESC, 'population')

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.

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

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?

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.

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.

I just tried this in the install environment and it does not work. There are probably changes to ubiquity that need to happen.

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

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.

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?!

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

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/

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.

Based on comment #34 unfortunately moving this to s-series.

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/

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.

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

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

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.

This issue has sat incomplete for more than 60 days now. I'm going to close it as invalid. Please feel free re-open if this is still an issue for you. Thank you.