Factory reset, several upgrades->3.2.0 : Timezone issues [solution]

Question

10

Factory reset, several upgrades->3.2.0 : Timezone issues [solution]

bug

asked 2019-10-30 14:11:19 +0300

yomark
756 ●7 ●9 ●14

updated 2019-10-31 12:51:44 +0300

So, after the update bricked my phone yesterday, I did a factory reset from recovery, and let it update itself to 3.2.0 again. Now I have the issue that my time/timezone is one hour wrong when using network time(for example 11:43 in stead of the correct time 12:43). I'm living in the Netherlands. However, a website like https://browserspy.dk/date.php diplays the correct time(uses webborwser exposed time).

When I set it to the correct time manually(selecting the right timezone) apps like SailOTP do not work anymore. https://browserspy.dk/date.php gives a 3600 second offset.

Any ideas?

I found the GetNetworkTime command somewhere else(output seems correct to me - but sailfish does not account for the 3600 seconds timezone difference):

[nemo@Sailfish ~]$ date
Wed Oct 30 12:08:17 UTC 2019
[nemo@Sailfish ~]$ dbus-send --system --print-reply --type=method_call --dest=or                     g.ofono /ril_0 org.ofono.NetworkTime.GetNetworkTime
method return time=1572437299.391202 sender=:1.7 -> destination=:1.138 serial=54                     0 reply_serial=2
   array [
      dict entry(
         string "UTC"
         variant             int64 1572436537
      )
      dict entry(
         string "DST"
         variant             uint32 0
      )
      dict entry(
         string "Received"
         variant             int64 58
      )
      dict entry(
         string "Timezone"
         variant             int32 3600
      )
      dict entry(
         string "MobileCountryCode"
         variant             string "204"
      )
      dict entry(
         string "MobileNetworkCode"
         variant             string "16"
      )
   ]
[nemo@Sailfish ~]$

edit retag flag offensive close delete

Accepted Answer

7

answered 2019-11-11 02:13:26 +0300

olf
10393 ●104 ●201 ●158

updated 2019-11-19 03:13:21 +0300

This RPM symlink conflict seem to be a common flaw.
On an Xperia X, freshly upgraded from SailfishOS 3.0.3 to 3.2.0.12:

# ls -l /etc/ localtime*
lrwxrwxrwx 1 root root             25 2019-11-09 23:22 localtime -> ../usr/share/zoneinfo/UTC
lrwxrwxrwx 1 root root             24 2019-08-19 13:49 localtime.rpmnew -> /var/lib/timed/localtime
lrwxrwxrwx 1 root root             24 2019-05-07 21:40 localtime.rpmsave -> /var/lib/timed/localtime

So after reading @spiiroin's and @yomark's comments to @spiiroin's answer, I removed all these links, created a correct one and set timedclient-qt5:

devel-su
cd /etc
rm -v localtime*
ln -sv ../var/lib/timed/localtime localtime

If you want to have the timezone automatically adjusted to the timezone of the mobile network you are using (requires a SIM card), then execute
timedclient-qt5 --set-info=timeNitz --set-info=timezoneCellular=Europe/Amsterdam
If you want to use a fixed ("home") timezone or do not have a SIM card inserted, then execute
timedclient-qt5 --set-info=timeNitz --set-info=timezoneManual=Europe/Amsterdam

You may want to substitute Europe/Amsterdam with another timezone identifier from /usr/share/zoneinfo/.

Works fine (after waiting some minutes, presumably for ntpd, as tested without a SIM card), thanks!

Notes

@spiiroin, as I tested this without a SIM card, I promptly ran into the years old bug, that setting "Automatic update" at the GUI automatically sets the timezone to Finland/Helsinki (and apparently timedclient-qt5 --set-info=timeNitz --set-info=timezoneCellular=Europe/Amsterdam too, despite explicitly setting Europe/Amsterdam) without a SIM / mobile network connection.
I wonder, why the original symlink in the timed~~client-qt5~~ package is utilising an absolute path, as relative paths (as used by the original, wrong symlink in place) are usually preferable (e.g. when remounting the root volume at a different location, as this /var is on the same volume as /etc).
Hence using a relative one.

edit flag offensive delete publish link

Comments

@olf (1) Can and has been argued to be a feature... If device does have cellular capability (all phones) settings ui only allows selecting between fully automatic and fully manual -> automatic tz comes from built-in fallback, adaptation/product configured fallback, guestimated from mcc / mnc / nitz data -> not having a sim in = one of the fallbacks ends up used (this is where that timedclient incantation helps i.e. settings ui can be bypassed and tz selected manually while still keeping ntp based time sync enabled).

(2) Most likely reason for absolute paths: It has always been like that and there has been no reason to change it. [Also: It is timed package, not timedclient]

spiiroin ( 2019-11-11 15:01:16 +0300 )edit

2

@spiiroin, thank you for your prompt reply, although I believe for the tech-savvy SailfishOS adopters (each of them had to flash their devices first, before getting here), the approach "[on] all phones settings ui only allows selecting between fully automatic and fully manual" is annoyingly simplistic.

But as you nicely provided guidance for setting this in a more differentiated manner at the command line per timedclient-qt5, it is fine for me now (and supposedly for everyone, who finds this thread at TJC).

BTW @spiiroin, kudos for providing explanations and guidance for so many things lately, which are related to your work at Jolla: This is really helpful and provides insights into design decisions and their implementation.
There seems to be a slight shift in Jolla's policy in 2019, as many Jolla employees have become more active at TJC, but you are among the most active ones and most often provide relevant background info!

olf ( 2019-11-11 16:11:16 +0300 )edit

@olf, Thank you for that great manual how to get back the working automatic time update and automatic time zone. On my Jolla 1 time was also 1hour off from the correct time in Austria. Manual set time was only shown in the GUI but the programs e.g. Email, Messages, .. did not recongnize the manual correction of the time. Thanks to your procedure everything is working now again.

Stefan P ( 2019-11-18 22:49:57 +0300 )edit

@olf @spiiroin. Many Thanks. This really has helped. Last weekend J1 had a need for factory reset and thus to step through the whole history of SFOS, ending up with that timezone wrong issue. Notably at terminal "date" always had returned UTC. now CET as correct.

reakolia ( 2019-11-27 00:05:55 +0300 )edit

Answer 2

3

answered 2019-10-30 14:33:33 +0300

spiiroin
13237 ●151 ●224 ●199

moderator

From cli you can enable automatic system time sync (nitz + ntp) and still retain manually selected timezone.

You could try if something like this makes any difference:

timedclient-qt5 --set-info=timeNitz --set-info=timezoneManual=Europe/Amsterdam

The change can be reverted by going to Settings -> Time and date and then disabling and re-enabling automatic update.

edit flag offensive delete publish link

Comments

Hello @spiiroin, tnx for you response. That seems to work from a GUI standpoint. I'm now able to select the timezone with automatic time on. However, the time on my phone stays the same.

I even rebooted the phone, but no difference.

This(probably very unsupported, and has numerous downsides ) does seem to work for the 5 minutes I tested it...

[root@Sailfish nemo]# rm /etc/localtime
rm: remove symbolic link `/etc/localtime'? y
[root@Sailfish nemo]# cd /etc/
[root@Sailfish etc]# ln -s  ../usr/share/zoneinfo/CET /etc/localtime

I need time/date/appointments to work, otherwise things end badly for me in my work environment. :)

Was anything changed in 3.2.0 that could cause these issues? I never had problems with time/timezones pre-factory reset.

yomark ( 2019-10-30 14:51:56 +0300 )edit

1

@yomark I don't know if your issue is coming from this change, but actually, I've corrected a Qt bug for the reading of the time zone following a symlink from /etc/localtime, see https://bugreports.qt.io/browse/QTBUG-75936 . This bug fix was backported in SailfishOS version of Qt (see https://git.sailfishos.org/mer-core/qtbase/merge_requests/44 ).

As I said, I don't know if its related and I'm sorry if it's causing you issues. The ofono DBus call you're mentioning is giving me more or less the same results with a timezone at +3600 (I'm Europe/Paris time).

Damien Caliste ( 2019-10-30 16:49:14 +0300 )edit

@Damien Caliste : no worries, all seems to work fine for me now(with my own hacky solution). And thanks for your response.

It could very well be that the issue is caused by me restoring settings(by copying contents from the nemo user folder) or something like that. However, all the rest seems fine.

yomark ( 2019-10-30 18:46:33 +0300 )edit

1

@yomark There used to be ownership conflict for /etc/localtime between libc and timed packages which got resolved recently. In internal development head there were situations where the symlink set up during timed install/upgrade could end up being removed as part of libc upgrade actions, but that was not supposed to happen when updating between releases. Nevertheless - if that happens, all of tz handling from timed up to settings ui fails to accomplish anything.

Do you remember what your /etc/localtime was before you removed it?

It is supposed to be a symlink to /var/lib/timed/localtime owned by timed-qt5 package, something like:

[nemo@Sailfish ~]$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 24 Oct  3 16:52 /etc/localtime -> /var/lib/timed/localtime
[nemo@Sailfish ~]$ rpm -qf /etc/localtime
timed-qt5-<VERSION>.jolla.armv7hl

spiiroin ( 2019-10-31 07:35:35 +0300 )edit

3

@spiiroin : I do not know the ownership of the old symlink, but it was pointing to ../usr/share/zoneinfo/UTC (so basically, I only changed UTC to CET )and certainly not to /var/lib/timed/localtime

So, symlink should point to /var/lib/timed/localtime? (makes sense to me now, as the problem I experience is that timed daemon seems to work fine, and timedclient-qt5 output as well. It just seems sidelined)

Seems that somewhere in the upgrade process(multiple OS versions after factory reset) something went wrong in the way you describe.

edit:

[root@Sailfish nemo]#  rpm -qf /etc/localtime
timed-qt5-3.5.2-1.4.1.jolla.armv7hl

root@Sailfish etc]# rm /etc/localtime
rm: remove symbolic link `/etc/localtime'? y
[root@Sailfish etc]# ln -s  /var/lib/timed/localtime /etc/localtime
[root@Sailfish etc]# ls -la | grep localtime
lrwxrwxrwx  1 root root             24 Oct 31 11:07 localtime -> /var/lib/timed/localtime
lrwxrwxrwx  1 root root             24 Aug 19 15:49 localtime.rpmnew -> /var/lib/timed/localtime
lrwxrwxrwx  1 root root             24 Oct 29 23:29 localtime.rpmsave -> /var/lib/timed/localtime
[root@Sailfish etc]#

Rebooted the device --> time is good now!!

yomark ( 2019-10-31 11:43:48 +0300 )edit

Factory reset, several upgrades->3.2.0 : Timezone issues [solution]

2 Answers

Comments

Comments

Question tools

Stats

Related questions

Factory reset, several upgrades->3.2.0 : Timezone issues [solution]

2 Answers

Comments

Comments

Question tools

Public thread

Stats

Related questions