Re: qtMoko getting bad Network Time

[Paul Wise]

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.

-- 
bye,
pabs

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: qtMoko getting bad Network Time

[Jorge]

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


Jorge

On 05/01/15 23:39, Paul Wise wrote:

On Mon, Jan 5, 2015 at 2:15 AM, Jorge wrote:


I have a correctly set time & timezone (America/Montevideo), and when my
qtMoko boots up, after connecting to the cellular network a weird dialog
appears : "The network time is (GMT +34). Set this new time?". If I say No,
everything keeps working. If I say Yes the timezone is changed to "GMT-34"
and as expected the time is borked (00:00 1/1/1970).

34 hours past GMT sounds like your provider has a broken time server.
Usually GMT timezones are 0-12 hours before/after GMT and no further.
Of course QtMoko should probably handle such broken timezones by
ignoring them rather than breaking. Please file a bug about it on the
QtMoko bug reports page:

https://github.com/radekp/qtmoko/issues




___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community