Bug: automatic time zone set not correct
When i'm enable automatic time & date sync, Jolla in my time zone Yekaterinburg (GMT+6), set Moskow (GMT+4). It's not right.
We have moved to a new Sailfish OS Forum. Please start new discussions there.
When i'm enable automatic time & date sync, Jolla in my time zone Yekaterinburg (GMT+6), set Moskow (GMT+4). It's not right.
If you have the developer mode enabled, type this on the console to see what time zone gets reported by your operator:
dbus-send --system --print-reply --type=method_call --dest=org.ofono /ril_0 org.ofono.NetworkTime.GetNetworkTime
Look for the "Timezone" entry, the value is UTC offset in minutes.
@slava: How would a successful answer look like? I get an empty array:
[nemo@Jolla ~]$ dbus-send --system --print-reply --type=method_call --dest=org.ofono /ril_0 org.ofono.NetworkTime.GetNetworkTime
method return sender=:1.14 -> dest=:1.868 reply_serial=2
array [
]
Stefanix (
2015-01-07 11:46:33 +0200
)editIt means that Jolla never received the NITZ (Network Identity and Time Zone) message from your operator (MTS?) so it has no idea what the real timezone is. MCC (250) only tells you which country you are in. Most Russian people live in the Moscow time zone, so it's the best bet :) The good answer would look like this (MTS/St.Petersburg):
[nemo@Jolla ~]$ dbus-send --system --print-reply --type=method_call --dest=org.ofono /ril_0 org.ofono.NetworkTime.GetNetworkTime
method return sender=:1.13 -> dest=:1.1816 reply_serial=2
array [
dict entry(
string "UTC"
variant int64 1420621143
)
dict entry(
string "DST"
variant uint32 0
)
dict entry(
string "Received"
variant int64 79556
)
dict entry(
string "Timezone"
variant int32 10800
)
dict entry(
string "MobileCountryCode"
variant string "250"
)
dict entry(
string "MobileNetworkCode"
variant string "01"
)
]
slava (
2015-01-07 12:03:23 +0200
)editMy operator Motiv in Yekaterinburg sends NITZ messages. I have this:
array [
dict entry(
string "UTC"
variant int64 1425716124
)
dict entry(
string "DST"
variant uint32 0
)
dict entry(
string "Received"
variant int64 3026405
)
dict entry(
string "Timezone"
variant int32 18000
)
dict entry(
string "MobileCountryCode"
variant string "250"
)
dict entry(
string "MobileNetworkCode"
variant string "35"
)
]
But there are a some questions: 1) What is the time format? "UTC" value is 1425716124. If it is Unix time that it is Sat, 07 Mar 2015 08:15:24 GMT. But now the time is Mon, 09 Mar 2015 14:04:00 GMT. 2) What is "Received" value? (3026405). 3) The "Timezone" value is 18000. I have UTC+5 (MSK+2, RTZ 4). How to convert that value?))
It will be good if somebody has information about NITZ protocol.
Lightning ( 2015-03-09 16:16:01 +0200 )editI can confirm that obviously SFOS can not read the timezone information as provided by mobile operator T-Mobile-US. ( I'll try to check this behavior at other regions and operators with any next travel). It appears to me as a bug, with all SFOS releases up to now. During last few years, always wondering why 'EST' was selected as timezone, even having touched down first at USA West coast. In January 2016 I traveled at various time-zones throughout the USA. At same time a Nokia 6310i recognized nicely the various time-zones. Whereas the Jolla turned to 'EST (NewYork)' always, whenever time selection is configured for 'automatic'. Both devices, the Jolla and the Nokia 6310i used same network of T-Mobile-US at same time.
My Jolla also selects US Eastern time when connected to T-Mobile in US Mountain time. Here is the output from GetNetworkTime:
[nemo@Jolla ~]$ dbus-send --system --print-reply
--type=method_call --dest=org.ofono /ril_0 org.
ofono.NetworkTime.GetNetworkTime
method return sender=:1.9 -> dest=:1.29339 reply
_serial=2
array [
dict entry(
string "UTC"
variant int64 1455489508
)
dict entry(
string "DST"
[nemo@Jolla ~]$
)
dict entry(
string "Received"
variant int64 712255
)
dict entry(
string "Timezone"
variant int32 -25200
)
dict entry(
string "MobileCountryCode"
variant string "310"
)
dict entry(
string "MobileNetworkCode"
variant string "260"
)
Later in Germany, as expected as T-Mobile.DE is not supporting this, and also 6310i has nothing to react on:
[nemo@Jolla ~]$ dbus-send --system --print-reply --type=method_call --dest=org.ofono /ril_0 org.ofono.NetworkTime.GetNetworkTime
method return sender=:1.7 -> dest=:1.906 reply_serial=2
array [
]
reakolia (
2016-02-28 02:22:14 +0200
)editI also have noticed that the automatic time sync does not work right. It has been a few times when my Jolla has changed itself automatically to UTC time. When I've checked the settings, it showed a "," in the place of a time zone. I also couldn't find Finland in time zone list.
What I did was turn automatic time update off and set the time zone manually to another GMT+2 time.
Following conditions apply to me:
Does anyone else have same kind of problem, or is it just my phone and how can I fix it?
At wikipedia dot org there is an article about whether various mobile provider supporting Network Identity and Time Zone (NITZ) , In addition there at reference '5' it is stated that the time feature is about a kind of license to buy from Mobile System Supplier.
reakolia ( 2016-02-28 02:10:09 +0200 )editThis thread is public, all members of Together.Jolla.Com can read this page.
Asked: 2014-02-19 07:19:23 +0200
Seen: 991 times
Last updated: Feb 19 '16
[Fixed in 1.0.3.8] Crash when linking contacts? [not relevant]
Time slider usage in video player of Gallery app causes the app to hang [duplicate]
QAudioOutput isn't integrated with system volume and libresource like QMediaPlayer
Bug: E-Mail synchronization does not work as configured [released]
Word prediction should be always turned off when entering passwords in Android apps [released]
Don't enforce focus to textfield [answered]
[Implemented in 1.0.3.8] Email: Honour Reply-To header [answered]
What's your MCC/MNC? To find out, cat the following statefs entries:
slava ( 2014-12-19 02:27:03 +0200 )edit250 01 01 250 And so what it mean?
norguhtar ( 2014-12-19 06:32:22 +0200 )editThere are MTS codes. I can confirm that Beeline (250 99) also broadcast wrong Moscow time in Yekaterinburg timezone area. I never trust to mobile operators and using NTP on other devices for setting time. But on Jolla using NTP is another problem: https://together.jolla.com/question/5064/option-ntp-for-automatic-time-update/ .
fLegmatik ( 2014-12-20 07:11:29 +0200 )edit