Opened 10 years ago

Last modified 6 years ago

#214 reopened defect

Timezone is lost across reboots, clock shifts

Reported by: carllobo Owned by: ainulindale
Priority: major Milestone:
Component: shr-settings Version: SHR-core
Keywords: Cc:

Description

For me at least - I have my system clock set to UTC and my timezone set to IST using /etc/default/rcS and /etc/localtime - everytime my phone is rebooted it shows me weird times. To fix it I had to change line number 54 of /etc/init.d/hwclock.sh from
hwclock --systohc
to
TZ="$TZ" hwclock --systohc

Attachments (4)

hwclock.sh (2.2 KB) - added by Kareema 10 years ago.
/etc/init.d/hwclock.sh
hwclock.sh.patch (783 bytes) - added by c_schwamborn 6 years ago.
shr_clock.py.patch (1.6 KB) - added by c_schwamborn 6 years ago.
shr_ntp.py.patch (1.2 KB) - added by c_schwamborn 6 years ago.

Download all attachments as: .zip

Change History (15)

Changed 10 years ago by Kareema

/etc/init.d/hwclock.sh

comment:1 in reply to: ↑ description Changed 10 years ago by Kareema

Replying to carllobo:

I had the problem of incorrect system time after reboot, too. Seems like http://docs.openmoko.org/trac/ticket/1851. My settings:

symlink: /etc/localtime -> /usr/share/zoneinfo/Europe/Berlin
/etc/default/rcS: UTC=yes

I could get the correct time after reboot using /etc/init.d/hwclock.sh from OM2008.12/testing. File is attached.

P.S.: It shouldn't be necessary to set TZ via /etc/default/rcS if you have set your local time using /etc/localtime.

comment:2 Changed 10 years ago by mrmoku

  • Resolution set to fixed
  • Status changed from new to closed

I just tried that with a current unstable image and timezone set to Europe/Berlin?.
Note: you have to install tzdate-europe to have that timezone installed.

After a reboot the time is still correct.

comment:3 Changed 6 years ago by Thamos0815

  • Component changed from SHR Image to SHR config
  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Version set to SHR-core

It happens again at my place. I set time with Settings, Date/Time? dialog. Regardless if i set directly, or use ntp time-server, hwclock and system clock are set to that time. After reboot the hwclock is assumed to be utc and i get the now wrong offset of 2 hours added for my Timezone (Europe/Berlin?)

I've recently done opkg update and opkg upgrade, but the problem exits for a longer time.

comment:4 Changed 6 years ago by Thamos0815

  • Component changed from SHR config to shr-settings

comment:5 Changed 6 years ago by Thamos0815

i've done some more research. When using dbus, as follows, i always got the rtc-clock added by the timezone-offset:
date -d @$(mdbus2 -s org.freesmartphone.odeviced /org/freesmartphone/Device/RTC/0 org.freesmartphone.Device.RealtimeClock?.GetCurrentTime? | cut -b 2-11 )

i think the problem is, that the Date/Time? dialog and ntp-client doesn't save in utc to hwclock.

comment:6 Changed 6 years ago by Thamos0815

When i set the using fso, the hwclock is set correctly to utc (in my case -2h), so that the time reported by fso rtc is my correct local time. So i guess the fault is somewhere in the setting process of the dialog and the ntp-client.

comment:7 Changed 6 years ago by Thamos0815

  • Summary changed from Timezone is lost across reboots to Timezone is lost across reboots, clock shifts

i have located the problem in two places:
1.) in line 32 of shr_clock.py in shr_settings_modules the time is set directly with hwclock -w . I would suggest an aproach with the fso-interface like i did above. Since i am not familiar with python (and dbus and fso, too) i can not provide a patch.
2.) The shr_ntp.py module uses the file /etc/default/rcS to determine if it should start the ntp with utc option or not. This file is not present on my system(anymore?) Maybe i should have created it, but i thought shr is always running with localtime in utc?

comment:8 Changed 6 years ago by gerhard

For me this problem does not occur when I create the /etc/timezone link, pointing to the same zoneinfo file as /etc/localtime does.

comment:9 Changed 6 years ago by c_schwamborn

Apart from the possibility Thamos0815 pointed out, to use the dbus interface fso provides to communicate with the RTC, there are some pieces missing:

1.) There is a link: /etc/localtime -> /usr/share/zoneinfo/Europe/Berlin. But since /usr/share/zoneinfo is nowadays usually the timezone directory, there should be another link: /usr/share/zoneinfo/localtime -> /etc/localtime as debian does it. But this doesn't cause the problems here I think.

2.) /etc/init.d/hwclock.sh calls 'hwclock --hctosys' regardless of what is configured in /etc/default/rcS about the hw clock using localtime or utc. At least shr_ntp.py evaluates 'UTC=yes' in /etc/default/rcS to call hwclock with or without '-u'.
So setting 'UTC=yes' in /etc/default/rcS will fix the problem shr_ntp.py causes while setting the clock using ntp, but nevertheless /etc/init.d/hwclock.sh should also evaluate 'UTC=yes'. Btw shr_ntp.py reports the wrong file missing if /etc/default/rcS isn't present.

3.) shr_clock.py also ignores the UTC setting in /etc/default/rcS when writing the systemdate to the RTC.

4.) Last but not least: Since most linux systems prefer using UTC in the hardware clock, the whole config shoulb be turned around, to make usind UTC default. In this case 'UTC=no' in /etc/default/rcS would switch to use localtime in RTC or UTC if ommited.

Most important: All systemparts handling the time should set/restore the time to/from the RTC in either UTC or localtime, but not mixed. I haven't looked at the fso interface jet, but if fso can handle all the time stuff it should be handled there in one place and not scattered around the system

The patches I attached flip the behaviour of shr_ntp.py regarding 'UTC=xxx' in /etc/default/rcS and add the evaluation of 'UTC=no' to hwclock.sh and shr_clock.py. The result should be that the 'UTC' setting /etc/default/rcS isn't needed, unless you want to store your localtime in RTC, the you have to provide 'UTC=no' in /etc/default/rcS. For now I fixed whats there, but I will try to look into the dbus interface of fso.

Changed 6 years ago by c_schwamborn

Changed 6 years ago by c_schwamborn

Changed 6 years ago by c_schwamborn

comment:10 Changed 6 years ago by jama

What SHR version are you using? current shr-core does not provide /etc/default/rcS by default and hwclock.sh SYSV script is even blacklisted in systemd config.

comment:11 Changed 6 years ago by c_schwamborn

I'm using shr-core from 2012-10-22 and I know that /etc/default/rcS is not privided by default what seems to be the problem when using time setting dialogs (either ntp or manual) in shr-settings since as I said: Hwclock is used there and writes the localtime to RTC (if /etc/default/rcS doesn't exist in case of ntp and manual does it anyways). I also noticed that hwclock.sh seems not used at the moment, but I fixed it anyways.
How is the systemclock currently set at startup in shr-core anyways?

Note: See TracTickets for help on using tickets.