Time zone setting - Githubissues

ChiefPete commented 1 year ago

I just installed watchmate via flatpak on my pinephone running postmarketos with sxmo. Watchmate works, but it set my watch's time to UTC. Is there a config somewhere to set a time zone?

azymohliad commented 1 year ago

Hey, no, there's no timezone config, and it should set it to the local time by default, so it's a bug, likely coming from chrono dependency. I assume assume it's the same issue as this. I see that there's a new chrono release which includes a potential fix. I'll try to update it, probably later today.

ChiefPete commented 1 year ago

Sounds good. I didn't know about the move from gitlab to github, and didn't know about the previous bug.

Thanks for making this app.

azymohliad commented 1 year ago

Yeah, a bunch of older issue reports aren't discoverable because of migration, sorry for that.

I just checked, turns out v0.4.4 already uses the latest chrono (I must've updated it together with some other dependencies without noticing), so unfortunately this will take some more debugging, and I'll have to dive deeper into chrono code.

What's your timezone (to understand how far it's off)? Also, could you check if the hardware clock is in UTC (there's no timedatectl on pmOS, so I guess sudo hwclock --verbose should work).

ChiefPete commented 1 year ago

I'm on Central Daylight savings time. - UTC -5

pine64-pinephone:~$ hwclock --verbose
hwclock from util-linux 2.38.1
System Time: 1681146607.138672
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2023/04/10 17:10:09
Hw clock time : 2023/04/10 17:10:09 = 1681146609 seconds since 1969
Time since last adjustment is 1681146609 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2023-04-10 12:10:07.417565-05:00

azymohliad commented 1 year ago

Ok, so the hardware clock is set to UTC, which is the same I have on all my devices, so it's not related to that. I cannot reproduce it on my pmOS/Phosh PinePhone, tried different timezones as well just in case it could be something timezone-specific. So now I don't really have any idea where to look. I can make a build with some extra logs which might be helpful, if you would have time to try it.

ChiefPete commented 1 year ago

I would be willing to do some testing/debugging.

azymohliad commented 1 year ago

Thank you, and sorry for the silence. It turned out I have the next few days fully occupied (including evenings), so I'll try to add some meaningful logs this weekend.

KaffeinatedKat commented 1 year ago

I am having the same issue, postmarketos with sxmo. I am also willing to do some testing whenever you have the time to add some logs

azymohliad commented 1 year ago

Hey, so I've added some extra logs to forked chrono library (diff) and switched to it in debug-timezone branch. You can install the build from Flathub CI the following way:

flatpak install https://dl.flathub.org/build-repo/17995/io.gitlab.azymohliad.WatchMate.flatpakref

And then run with debug logs enabled:

flatpak run --env=RUST_LOG=infinitime=debug,chrono=debug io.gitlab.azymohliad.WatchMate

I expect in between other logs you'll see:

Reading timezone failed: ...
...
Fallback timezone readout failed too. Falling back to UTC

But it would be useful to confirm this and see the exact errors.

KaffeinatedKat commented 1 year ago

[INFO  watchmate::ui::devices] Trying to connect to InfiniTime (FD:D6:9A:91:9F:A0)
[ERROR watchmate::ui::devices] Connection failure: Bluetooth operation failed: le-connection-abort-by-local
[INFO  watchmate::ui::devices] Discovery started
[INFO  watchmate::ui::devices] Discovery stopped
[INFO  watchmate::ui] Device connected: FD:D6:9A:91:9F:A0
[DEBUG infinitime::bluetooth::services] Current time requested
[DEBUG chrono::offset::local::inner] Reading timezone from: None
[DEBUG chrono::offset::local::tz_info::timezone] Posix timezone string: localtime
[DEBUG chrono::offset::local::tz_info::parser] Timezone data header: Header { version: V2, ut_local_count: 0, std_wall_count: 0, leap_count: 0, transition_count: 0, type_count: 1, char_count: 4 }
[DEBUG chrono::offset::local::inner] Timezone cache: Cache { zone: TimeZone { transitions: [], local_time_types: [LocalTimeType { ut_offset: 0, is_dst: false, name: Some("UTC") }], leap_seconds: [], extra_rule: Some(Fixed(LocalTimeType {
ut_offset: 0, is_dst: false, name: Some("UTC") })) }, source: LocalTime { mtime: SystemTime { tv_sec: 1681660281, tv_nsec: 586302572 } }, last_checked: SystemTime { tv_sec: 1681660288, tv_nsec: 484413812 } }
[DEBUG infinitime::bluetooth::services] Local time: 2023-04-16 15:51:28.484386187 +00:00
[DEBUG infinitime::bluetooth::services] UTC time: 2023-04-16 15:51:28.484386187

Appears to not be able to find the timezone, as it's reading from the timezone None

azymohliad commented 1 year ago

Thanks for such a fast response!

Appears to not be able to find the timezone, as it's reading from the timezone None

That log is just not very descriptive, it actually indicates that there's no TZ environment variable, so it continues to read from the next source, which is /etc/localtime. And unlike what I expected, it reads it without errors from there, but somehow parses it as UTC. Where does your /etc/localtime symlink points to?

KaffeinatedKat commented 1 year ago

/etc/localtime -> /etc/zoneinfo/America/Denver this is my timezone, if I do export TZ=America/Denver then it does set the time correctly

ChiefPete commented 1 year ago

I'm running PostmarketOS Edge with SXMO. I've followed your instructions to install/run WatchMate with extra debugging.

I can't find the logs. Where to look?

azymohliad commented 1 year ago

@ChiefPete if you run it from the terminal with the command below, then it should just print it out to the terminal.

flatpak run --env=RUST_LOG=infinitime=debug,chrono=debug io.gitlab.azymohliad.WatchMate

You can also redirect them to a file by appending &> log.txt at the end of the command.

azymohliad commented 1 year ago

@KaffeinatedKat, hm, that's really interesting. Thanks!. Looking into it

azymohliad commented 1 year ago

@KaffeinatedKat, so it parses your /etc/zoneinfo/America/Denver incorrectly. First of all, it's curious that it links to /etc/zoneinfo/, and not /usr/share/zoneinfo/. Could you check, if the file is actually there? If yes, could you upload it here? Also what's the content of /etc/zoneinfo/: does it match it in /usr/share/zoneinfo/ or has fewer entries? And just to be sure, is tzdata package content installed to /usr/share or /etc (apk info -L tzdata)?

azymohliad commented 1 year ago

I've read a bit more about Alpine timezone management, and realized tzdata might not be installed (I have it as an indirect dependency for Phosh), because Alpine includes setup-timezone script, which can install only needed zoneinfo files directly to /etc/zoneinfo. And SXMO makes use of this script. I thought I'd be able to reproduce it on my pmOS/Phosh Pinephone after running setup-timezone -z America/Denver manually, but nope. So your /etc/zoneinfo/America/Denver file would still be helpful, but other info I asked above - not so much anymore.

ChiefPete commented 1 year ago

Here is a link to my timezone file /etc/zoneinfo/America/Menominee . This is from PostmarketOS Edge

My timezone file

azymohliad commented 1 year ago

Thank you! Ok, I think I finally understand what's happening. It's a sandboxing issue: flatpak doesn't use host's /etc, and it recreates /etc/localtime symlink inside the container, but not pointing to the same file as host, rather it looks up the corresponding file in /usr/share/zoneinfo and links to that. If it cannot find it, it fallbacks to /usr/share/zoneinfo/UTC.

I assume you don't have tzdata package installed, and if I got everything correctly, installing it should fix it. Probably, flatpak package should depend on tzdata in Alpine/postmarketOS. I'll see where I can report that. I don't think anything better can be done on WatchMate side.

UPD: Actually, since Flatpak timezone handling goes somewhat against Alpine philosophy, requiring to install 3MB extra just for timezone lookup to work, what WatchMate can do better is to provide native Alpine package. But not sure when I'll look into that

ChiefPete commented 1 year ago

I do have the tzdata package installed. This package contains all of the zoneinfo files. Is there some command you are expecting called tzdata?

azymohliad commented 1 year ago

Ok, then I'm puzzled again. Yeah, all the zoneinfo files is what I expected would make it work, because then flatpak should be able to find the needed file and not fallback to UTC. I didn't mean any tzdata related command.

Could you launch WatchMate, and then while it's running, check the output of the following command?

flatpak enter io.gitlab.azymohliad.WatchMate ls -l /etc/localtime

KaffeinatedKat commented 1 year ago

flatpak enter io.gitlab.azymohliad.WatchMate ls -l /etc/localtime points to /usr/share/zoneinfo/UTC. I have tzdata installed and all the timezones are avalibable in /usr/share/zoneinfo

This is also my Denver timezone file

azymohliad commented 1 year ago

Thanks, this confirms that it's a sandboxing issue with flatpak. Now we need to figure out why it fails to find the correct file from tzdata

azymohliad commented 1 year ago

Hey, some updates here. I believe I got to the root of it.

Probable rootcause

Here is the Flatpak code responsible for timezone lookup. TL;DR the algorithm is the following:

Resolve the /etc/localtime symlink on the host
If TZDIR environment variable is set, and it matches /etc/localtime destination prefix, return the suffix
Else, if /etc/localtime destination prefix is /usr/share/zoneinfo, return the suffix
Else, if /etc/timezone exists, return its content.
Else, return UTC.

In other words, for Flatpak to be able to preserve the timezone from /etc/localtime which does not symlink to /usr/share/zoneinfo/..., its destination base directory path (e.g. /etc/zoneinfo) must be exported as TZDIR variable.

The reason I couldn't reproduce the issue with setup-timezone -z America/Denver (which makes it symlink to /etc/zoneinfo/...) is that I also had /etc/timezone present (probably created by Phosh stack), so it returned at step 4 and never reached step 5. If I remove it then I can reproduce. I guess you don't have /etc/timezone, do you?

This would mean that the issue is between Flatpak and Alpine's setup-timezone: either Flatpak should add /etc/zoneinfo to the lookup list, or setup-timezone -z should make sure TZDIR=/etc/zoneinfo is exported. But I'm not sure if there's a rigorous standard that defines how it should be, and hence which side to report it to. This also means that other Flatpak apps that read the timezone from /etc/localtime should have the same issue on pmOS/SXMO.

Workarounds

Until this is properly fixed there, here are some possible workarounds:

I think the best one is to export TZDIR=/etc/zoneinfo systemwide (e.g. in /etc/profile). This will fix the similar issue for all Flatpak apps, and potentially maybe for some other software, and it will be sensitive to timezone changes via setup-timezone or SXMO utils.
Another option is to save the timezone in /etc/timezone. This will also be for all Flatpak apps, but you'd have to remember to update it when changing the timezone.
If you dont want to affect anything else in the system, then setting TZ environment variable to your timezone name (i.e. America/Denver or America/Menominee) for WatchMate only is probably the best option. You can do it with Flatseal or the following command:
```
flatpak override --env=TZ=Continent/City io.gitlab.azymohliad.WatchMate
```

Let me know if any of these work and is suitable for you.

There are other options, but they don't make much sense to me. You can of course set TZ systemwide too, but it has the same disadvantage as /etc/timezone plus other Flatpak apps might still fallback to UTC (TZ is not used by Flatpak, but by WatchMate itself). Using TZDIR for WatchMate only doesn't make much sense either, it must be set in the host environment, so it won't have an effect with Flatpak's --env and you'd have to override the .desktop file or something.

azymohliad commented 1 year ago

I reported the issue to Flatpak and Alpine now.

Btw, did you folks had a change to try if those workarounds above work for you?

azymohliad commented 1 year ago

Wow, that was fast! Alpine pushed a fix (TZDIR export) 30 minutes after the report. It should reach postmarketOS at some point then

KaffeinatedKat commented 1 year ago

I reported the issue to https://github.com/flatpak/flatpak/issues/5399 and Alpine now. Btw, did you folks had a change to try if those workarounds above work for you?

I just added export TZ=America/Denver to watchmate and it works properly. Should do me good till postmarketOS gets that fix

azymohliad commented 1 year ago

Alright, I'll close the issue here then (feel free to reopen if any of the proposed workaround don't work). Thank you for your help with debugging it folks!

azymohliad / watchmate

Time zone setting #22

Probable rootcause

Workarounds