qtMoko getting bad Network Time

[Jorge]

Thanks.

I've found this wording for the time zone info [1][2]:

"(indicates the difference, expressed in quarters of an hour, between 
the local time and GMT; range
-96...+96)"

So, a value of 136 would not be valid. I'll try to track this one.


Jorge


[1] 
http://www.etsi.org/deliver/etsi_ts/127000_127099/127007/08.03.00_60/ts_127007v080300p.pdf
[2] download-c.huawei.com/download/downloadCenter?downloadId=16235

On 07/01/15 01:08, Paul Wise wrote:
> On Wed, Jan 7, 2015 at 8:51 AM, Jorge wrote:
>
>> Thanks for the confirmation. A question, can you confirm that the session
>> excerpt is the one of interest, and it actually says the provider is giving
>> the +34 time zone? That would be strange, being the biggest celular provider
>> around here. With my Nokia dumbphone I've never seen something like that
>> (OTOH, time updatting hasn't worked for me at all last time I needed it).
> America/Montevideo seems to be two hours behind UTC.
>
> The log confirms that QtMoko is definitely looking for the GMT-34 timezone.
>
> Looking at the QtMoko source code, +CTZV is an "Unsolicited result
> code for time zone change events".
>
> https://github.com/radekp/qtmoko/blob/master/doc/html/atcommands.html
>
> Your operator's CTZV value is 136.
>
> The code handling the +CTZV message is here:
>
> https://github.com/radekp/qtmoko/blob/master/devices/neo/src/plugins/phonevendors/neo/vendor_neo.cpp#L683
>
> That code produces 34 hours in front of UTC for your operator's CTZV value.
>
> There are two other FLOSS implementations of CTZV handling that I know
> of, FSO and oFono:
>
> http://www.freesmartphone.org/
> https://01.org/ofono
>
> Looking at the FSO code, it produces 8 hours behind UTC for your
> operator's CTZV value.
>
> https://github.com/freesmartphone/cornucopia/blob/master/fsogsmd/src/lib/consts.vala#L975
>
> Looking at the oFono code, it produces 34 hours in front of UTC for
> your operator's CTZV value.
>
> https://git.kernel.org/cgit/network/ofono/ofono.git/tree/drivers/atmodem/network-registration.c#n841
>
> I then tried to find a reference for how to do this correctly, since
> none of the FLOSS implementations I can find produce a result that
> matches TZ=America/Montevideo.
>
> The closest I could find is a reference to the value being an offset
> from Universal Time in units of 15 minutes.
>
> Not sure what the right answer is here, I think you will need to do
> more testing with the same SIM card in a variety of phones from you
> and your friends and record the resulting timezone offsets. If you can
> also record the CTZV value (some phones have debug info available)
> that would be helpful too, in case different phones get different
> values or use another command. Start by setting the timezone UTC, then
> turn on automatic timezone info and then find out what the resulting
> timezone offset is. If any of them then get the correct timezone
> you'll need to figure out how.
>