Cellphone tz updates often not happening in Israel
A couple of weeks ago there were widespread reports of problems in the tz database's updates getting propagated to end users in Israel. Many cellphones running Android, BlackBerry, iOS, and Symbian were still based on tz release 2012g or earlier, i.e., they had not updated even to tz release 2012h (2012-10-26), much less to the current rules for Israel as per tz release 2013d (2013-07-05). Hundreds of thousands of cellphones were reportedly affected by the problem, and some cellphone companies worked around the problem by advising their users to switch to Athens time. Unfortunately, Europe/Athens is also incorrect for Israel, as it gets the transition wrong by two hours this fall and by 49 hours next spring. And even if users were advised to switch back to Asia/Jerusalem after next month I wouldn't be surprised if some users forget, and run into a similar problem in March. I wonder why the cellphones' copies of the tz database are not being updated? My sources: Elis N. Israel does the time warp; daylight savings glitch wreaks havoc. Jerusalem Post 2013-09-08 http://www.jpost.com/Business/Business-Features/Israel-does-the-time-warp-da... Winer S. New daylight savings schedule baffles cellphones. The Times of Israel 2013-09-08 http://www.timesofisrael.com/new-daylight-savings-schedule-baffles-cellphone... Schuster R. Israel's mobile users go Greek. Haaretz 2013-09-08 http://www.haaretz.com/business/tech-roundup/1.545875
On Monday 2013-09-23 13:07 -0700, Paul Eggert wrote:
A couple of weeks ago there were widespread reports of problems in the tz database's updates getting propagated to end users in Israel. Many cellphones running Android, BlackBerry, iOS, and Symbian were still based on tz release 2012g or earlier, i.e., they had not updated even to tz release 2012h (2012-10-26), much less to the current rules for Israel as per tz release 2013d (2013-07-05).
It also seems odd that these phones didn't have their time adjusted as a result of receiving NITZ messages from cell towers with the correct UTC offset. I thought that using time and timezone information from the cell network was the typical default configuration on smartphones (which makes having an up-to-date timezone database less critical). Are there carriers in Israel that don't broadcast date and offset information from their cell towers? Or were the carriers broadcasting incorrect data? http://en.wikipedia.org/wiki/NITZ doesn't have information on Israeli carriers, but it also suggests that there are substantial numbers of mobile networks that don't provide timezone information. -David -- đ L. David Baron http://dbaron.org/ đ đ˘ Mozilla https://www.mozilla.org/ đ Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
On Sep 23, 2013, at 1:32 PM, "L. David Baron" <dbaron@dbaron.org> wrote:
It also seems odd that these phones didn't have their time adjusted as a result of receiving NITZ messages from cell towers with the correct UTC offset. I thought that using time and timezone information from the cell network was the typical default configuration on smartphones (which makes having an up-to-date timezone database less critical).
The C library in the smartphone OS that I think has the highest market share uses the tz code: https://github.com/android/platform_bionic/tree/master/libc/tzcode as does the C library in the smartphone OS that has the second-highest market share (as it's all Darwin down there). Whether, when running on a machine with mobile phone access, something in the software checks whether the time zone offset from the cell phone tower agrees with the time zone offset from the tzdb, and does something to handle that, is another matter.
On Sep 23, 2013, at 1:32 PM, "L. David Baron" <dbaron@dbaron.org> wrote:
Are there carriers in Israel that don't broadcast date and offset information from their cell towers? Or were the carriers broadcasting incorrect data?
Is the software that supplies the NITZ information using the tzdb and, if so, does *it* have up-to-date versions of tzdata?
http://en.wikipedia.org/wiki/NITZ doesn't have information on Israeli carriers, but it also suggests that there are substantial numbers of mobile networks that don't provide timezone information.
That article mentions Android and iOS - perhaps I should look a bit more at Bionic and Darwin to see if they has any provision for external overrides of the tzdb information. (Or perhaps Android has two separate chunks of code that handle time zone, and some other chunk does that; as I remember, OS X shares the tzdb between the tzcode in libSystem and some high-level (probably non-open-source) frameworks, so I suspect iOS does the same, and those high-level frameworks may support those external overrides.)
On Mon, Sep 23, 2013 at 03:33:43PM -0700, Guy Harris wrote:
On Sep 23, 2013, at 1:32 PM, "L. David Baron" <dbaron@dbaron.org> wrote:
http://en.wikipedia.org/wiki/NITZ doesn't have information on Israeli carriers, but it also suggests that there are substantial numbers of mobile networks that don't provide timezone information.
That article mentions Android and iOS - perhaps I should look a bit more at Bionic and Darwin to see if they has any provision for external overrides of the tzdb information. (Or perhaps Android has two separate chunks of code that handle time zone, and some other chunk does that; as I remember, OS X shares the tzdb between the tzcode in libSystem and some high-level (probably non-open-source) frameworks, so I suspect iOS does the same, and those high-level frameworks may support those external overrides.)
Most Android 2 and 3 devices are likely to have tzdata2010k. 90%+ of Android devices are non-upgradeable (for various reasons including: carriers will not provide upgrades, hardware is too weak to support new versions, etc.), so they have security vulnerabilities on top of any outdated TZ info. I'm aware that ClockSync and similar Android apps have an optional tzdata2013e library or the like, each for their own private use. Installing their tzdata2013e does not necessarily affect the system time zone options. This suggests any provision for external overrides of bundled tzdata is not system-wide on Android 2, 3, or 4. Analysis of AOSP releases themselves will trump that speculation, of course. Richard
On Sep 23, 2013, at 3:55 PM, Richard Johnson <rjohnson+tz@ucar.edu> wrote:
Most Android 2 and 3 devices are likely to have tzdata2010k. 90%+ of Android devices are non-upgradeable (for various reasons including: carriers will not provide upgrades, hardware is too weak to support new versions, etc.), so they have security vulnerabilities on top of any outdated TZ info.
Yeah, those were the reasons I was thinking of for the "if you can't update to an OS version with an updated version of the tzdb;" case. For OS X, only the "hardware is deemed too weak to support new versions" reason applies; I had the impression that updates came from the carrier for Android, and that might also get in the way of updating.
I'm aware that ClockSync and similar Android apps have an optional tzdata2013e library or the like, each for their own private use. Installing their tzdata2013e does not necessarily affect the system time zone options. This suggests any provision for external overrides of bundled tzdata is not system-wide on Android 2, 3, or 4.
I.e., that if there were a system-wide way of doing that, those apps would have to duplicate it? By "external override" I was thinking of something where, for example, some APIs would, at least if converting the *current* date/time, get the offset from both the tzdb and the carrier and, if they disagreed, discard the tzdb value and use the carrier's value instead.
Richard Johnson wrote:
Most Android 2 and 3 devices are likely to have tzdata2010k. 90%+ of Android devices are non-upgradeable (for various reasons including: carriers will not provide upgrades, hardware is too weak to support new versions, etc.), so they have security vulnerabilities on top of any outdated TZ info.
That's why I had suggested some time ago on this list to introduce a portable network protocol allowing tz data base updates, so the availability of data base updates would not depend on update packages provided by the OS distributors, which are usually only made available together with a firmware update. Martin
On Tue 2013-09-24T23:23:05 +0200, Martin Burnicki hath writ:
That's why I had suggested some time ago on this list to introduce a portable network protocol allowing tz data base updates, so the availability of data base updates would not depend on update packages provided by the OS distributors, which are usually only made available together with a firmware update.
This group works on that topic, has test implementations of protocols, and holds weekly telecons about progress http://calconnect.org/tc-timezone.shtml -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
Steve Allen wrote:
On Tue 2013-09-24T23:23:05 +0200, Martin Burnicki hath writ:
That's why I had suggested some time ago on this list to introduce a portable network protocol allowing tz data base updates, so the availability of data base updates would not depend on update packages provided by the OS distributors, which are usually only made available together with a firmware update.
This group works on that topic, has test implementations of protocols, and holds weekly telecons about progress
Thanks, Steve. Martin
and as chair of that tc I'd be very happy to talk to anybody interested in using that protocol. Briefly - we have a timezone server spec in draft http://tools.ietf.org/html/draft-douglass-timezone-service-08 which provides a simple protocol to list timezones, fetch them and provide expansions for easy conversion of times. On 09/26/2013 03:57 PM, Martin Burnicki wrote:
Steve Allen wrote:
On Tue 2013-09-24T23:23:05 +0200, Martin Burnicki hath writ:
That's why I had suggested some time ago on this list to introduce a portable network protocol allowing tz data base updates, so the availability of data base updates would not depend on update packages provided by the OS distributors, which are usually only made available together with a firmware update.
This group works on that topic, has test implementations of protocols, and holds weekly telecons about progress
Thanks, Steve.
Martin
On 23 Sep, 2013, at 16:32 , L. David Baron <dbaron@dbaron.org> wrote:
On Monday 2013-09-23 13:07 -0700, Paul Eggert wrote:
end users in Israel. Many cellphones running Android, BlackBerry, iOS, and Symbian were still based on tz release
My previous phone was a Symbian phone. I wouldn't update it since that generally made it worse than it already was...
It also seems odd that these phones didn't have their time adjusted as a result of receiving NITZ messages from cell towers with the correct UTC offset. I thought that using time and timezone information from the cell network was the typical default configuration on smartphones (which makes having an up-to-date timezone database less critical).
Are there carriers in Israel that don't broadcast date and offset information from their cell towers? Or were the carriers broadcasting incorrect data?
GSM towers traditionally had no idea what time or timezone it is, and many (maybe most) GSM and UMTS base stations still don't. NITZ isn't very common. I think the "TZ" part of NITZ may have been invented to solve a problem specific to American carriers, that they were deploying GSM into a market where the competing digital technologies (CDMA and IS-136 TDMA) could set the time and timezone on the handset and didn't want their GSM service to not have that feature too. I've seen the "NI" part of NITZ, without the TZ part, in use in China (despite what the Wikipedia page says) to identify the "area" the tower you were connected to was in, since they used to charge people different prices for calls in and out of their "home" area. In any case, outside of the Americas it is fairly rare to find a carrier which provides this service, so smartphones seem to often include plain old NTP and time zone files as a fall back while dumb phones need their clocks set by hand. Note that in the US mobile phone base stations always know what time it is since they pretty much always have GPS receivers, for E911 positioning if not for network time synchronization. In many other countries, however, it is considered a bad idea to allow your telecommunications infrastructure to become dependent on a service owned and operated by a foreign military so they are less likely to do this. Dennis Ferguson
the NITZ string doesn't include an olson id. if you look at GsmServiceStateTracker.java or the CDMA equivalent, you can see the heuristics for turning a gmt offset, country code, and "is_dst" flag into an olson id. (actually, every part of the NITZ string is optional.) cell towers can be misconfigured, which adds to the fun. plus there are places like the canary islands that don't have an MCC and don't share a time zone with the country that they share an MCC with. On Tue, Sep 24, 2013 at 9:42 AM, Dennis Ferguson < dennis.c.ferguson@gmail.com> wrote:
On 23 Sep, 2013, at 16:32 , L. David Baron <dbaron@dbaron.org> wrote:
On Monday 2013-09-23 13:07 -0700, Paul Eggert wrote:
end users in Israel. Many cellphones running Android, BlackBerry, iOS, and Symbian were still based on tz release
My previous phone was a Symbian phone. I wouldn't update it since that generally made it worse than it already was...
It also seems odd that these phones didn't have their time adjusted as a result of receiving NITZ messages from cell towers with the correct UTC offset. I thought that using time and timezone information from the cell network was the typical default configuration on smartphones (which makes having an up-to-date timezone database less critical).
Are there carriers in Israel that don't broadcast date and offset information from their cell towers? Or were the carriers broadcasting incorrect data?
GSM towers traditionally had no idea what time or timezone it is, and many (maybe most) GSM and UMTS base stations still don't. NITZ isn't very common. I think the "TZ" part of NITZ may have been invented to solve a problem specific to American carriers, that they were deploying GSM into a market where the competing digital technologies (CDMA and IS-136 TDMA) could set the time and timezone on the handset and didn't want their GSM service to not have that feature too. I've seen the "NI" part of NITZ, without the TZ part, in use in China (despite what the Wikipedia page says) to identify the "area" the tower you were connected to was in, since they used to charge people different prices for calls in and out of their "home" area. In any case, outside of the Americas it is fairly rare to find a carrier which provides this service, so smartphones seem to often include plain old NTP and time zone files as a fall back while dumb phones need their clocks set by hand.
Note that in the US mobile phone base stations always know what time it is since they pretty much always have GPS receivers, for E911 positioning if not for network time synchronization. In many other countries, however, it is considered a bad idea to allow your telecommunications infrastructure to become dependent on a service owned and operated by a foreign military so they are less likely to do this.
Dennis Ferguson
On Sep 23, 2013, at 1:07 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
I wonder why the cellphones' copies of the tz database are not being updated?
Perhaps there isn't an over-the-air automatic "update the tzdb" mechanism separate from the regular "update the OS" mechanism. (I don't think there's one for OS X.) If so, then: 1) if you can't update to an OS version with an updated version of the tzdb; 2) if the updates aren't over-the-air, and you haven't bothered to tether your phone to whatever machine provides updates; 3) if the updates are over-the-air, but aren't forced, and you didn't accept the update; your phone will get the wrong answer. (And if the binary format changes in ways that would cause older versions of the tz code not to be able to read them, or if there are bugs in older versions of the tz code that cause problems with current versions of the tz data, things get more complicated if you just try to push the latest data files to all phones.)
On Mon, 23 Sep 2013, Guy Harris wrote:
I wonder why the cellphones' copies of the tz database are not being updated?
Perhaps there isn't an over-the-air automatic "update the tzdb" mechanism separate from the regular "update the OS" mechanism.
This seems to have been the case. Following a warning message I sent at the end of August to Israel's Inter-University Computation Center mailing list warning that systems with timezone files that hadn't been updated after June (or at least after last November) would switch over to Standard Time seven weeks early on September 8, cellphone companies sent the following (or similar) SMS to all their customers (translated from the Hebrew original): Dear Customer, To avoid disruptions of the clock and event calendar of your device between 8/9 and 27/10 due to the changeover to winter time, go to Definitions->Time-and-Date and disable the automatic update option and change the timezone to Athens, Greece. For assistance, go to the URL etc. Even though Greece will change its clocks two hours later than Israel, I suppose it's better than seven weeks early ... _____________________________________ Ephraim Silverberg, CSE System Group, Hebrew University, Jerusalem, Israel. Phone/Fax number: +972-2-5494521
participants (10)
-
Dennis Ferguson -
enh -
Ephraim Silverberg -
Guy Harris -
L. David Baron -
Martin Burnicki -
Mike Douglass -
Paul Eggert -
Richard Johnson -
Steve Allen