In 1977 Tal Brody said after winning the Euroleague Basketball cup with Maccabi Tel Aviv as sentence which became quite famous in Israel:
“We are on the map! And we are staying on the map – not only in sports, but in everything.”
I found out through Invar Hovav that there’s a regression in the Ubuntu installation doesn’t believe this is true anymore, as according to lp#905754, you can’t select Israel or its major cities, and instead get suggestions for Gaza and Hebron. This is a regression from past installers when you could at least choose Tel Aviv, Jerusalem and Gaza. It used to be hard to pin point each location, but was still possible. This might be part of a bigger problem of selecting close/adjacent cities, but the default behavior in the past was different.
From the technical point of view, the Gaza and Hebron TZ files are weird (tzdata version 2011n-1). Both don’t have info for 2012 daylight saving time (usually start in late March or early April). Hebron switches twice a year to DST, hopefully nothing critical uses this time zone.
$ zdump -v Asia/Hebron | grep 2011
Asia/Hebron Fri Apr 1 10:00:59 2011 UTC = Fri Apr 1 12:00:59 2011 EET isdst=0 gmtoff=7200
Asia/Hebron Fri Apr 1 10:01:00 2011 UTC = Fri Apr 1 13:01:00 2011 EEST isdst=1 gmtoff=10800
Asia/Hebron Sun Jul 31 20:59:59 2011 UTC = Sun Jul 31 23:59:59 2011 EEST isdst=1 gmtoff=10800
Asia/Hebron Sun Jul 31 21:00:00 2011 UTC = Sun Jul 31 23:00:00 2011 EET isdst=0 gmtoff=7200
Asia/Hebron Mon Aug 29 21:59:59 2011 UTC = Mon Aug 29 23:59:59 2011 EET isdst=0 gmtoff=7200
Asia/Hebron Mon Aug 29 22:00:00 2011 UTC = Tue Aug 30 01:00:00 2011 EEST isdst=1 gmtoff=10800
Asia/Hebron Thu Sep 29 23:59:59 2011 UTC = Fri Sep 30 02:59:59 2011 EEST isdst=1 gmtoff=10800
Asia/Hebron Fri Sep 30 00:00:00 2011 UTC = Fri Sep 30 02:00:00 2011 EET isdst=0 gmtoff=7200
And Gaza only have a 3 months daylight saving time, while Israel has 6 and European eastern time has 7 months (all are UTC+2 region).
$ zdump -v Asia/Gaza | grep 2011
Asia/Gaza Sat Apr 2 10:00:59 2011 UTC = Sat Apr 2 12:00:59 2011 EET isdst=0 gmtoff=7200
Asia/Gaza Sat Apr 2 10:01:00 2011 UTC = Sat Apr 2 13:01:00 2011 EEST isdst=1 gmtoff=10800
Asia/Gaza Sun Jul 31 20:59:59 2011 UTC = Sun Jul 31 23:59:59 2011 EEST isdst=1 gmtoff=10800
Asia/Gaza Sun Jul 31 21:00:00 2011 UTC = Sun Jul 31 23:00:00 2011 EET isdst=0 gmtoff=7200
p.s.
This isn’t a political post, don’t make it into one.
Free Software Universe 
Id like to think that its not political, as an avid user it will sure won’t make me happy to think that someone did it on purpose ill join the bug discussion to follow its fix
It’s certainly not political and those people that suggest this in the bug report need to stop thinking they are the center of attention. Sometimes a bug is just this – a bug.
The TZ database changes at least certainly aren’t political. They’re an attempt to follow the changes to daylight savings policy on the ground. Gaza and Hebron are now taking different official stances on daylight savings time, neither of which match the Israeli policy, which forces splitting of the time zones (as always happens when localities do this).
The installation map thing strings me as a bug rather than malice: presumably however it works it wasn’t taking into account the possibility of multiple time zones in a small area. It should probably have some degree of population weighing involved in the algorithm or the like, as there are other areas in the world with concentrations of small time zones (some even directly overlapping the same area, as is the case in western China).
I know the reasons why Gaza and Hebron have different TZ files, but both seems weird and not to match what’s going on the facto.
Adding population weights sounds like a good idea.
Switching back from DST on Ramadan?
But yeah, looking at other time-zones files near by: did Egypt drop DST at 2011 with all the revolution? Or somebody forget to update the timezone database? Africa/Cairo does have Ramadan changes in 2010, like Asia/Hebron. Asia/Amman and Asia/Gaza don’t.
Lots of nearby time zones does appear to be the core problem here; the change of behaviour is, I think, just down to implementation skew, as we switched to a separate libtimezonemap library in Ubuntu 11.10. It might even come down to different rounding or something; I haven’t tracked it down in enough detail, and I don’t think the exact reason ultimately matters, but that sort of thing looks unpleasantly plausible from the code.
I’ve posted some analysis on the Ubuntu bug report. As I noted there, adding population weighting does have some appeal, but it sounds like a lot of volatile data to keep up to date, and I don’t think it really solves the core problem anyway: if you happen to be one of the people living in location A, it doesn’t really help you to be told that there are more people in nearby location B. It might adjust the incidence of the UI problem, but wouldn’t eliminate it. Coming up with a maintainable way (the old zoom behaviour didn’t turn out to be maintainable, unfortunately) to address the fundamental problem of requiring way too much fine motor control – and the degree of control required sometimes exceeding the resolution of the map – sounds like it would be a better long-term fix.
Yes, this is definitely not intentional. Thanks for bringing it up – I’ll try to work out what on earth is going on here tomorrow.