Incorrect time zone in multiple programs - timedatectl shows time zone as n/a

[SeerLite]

Hey again, basically what the title says. Different programs see different time zones. All programs are from the same stratum (Arch, hijacked). My bedrock config at /bedrock/etc/bedrock.conf has the timezone set correctly (haven't touched it since hijack).

My browser shows UTC+0, DIscord shows UTC-4. My actual timezone is UTC-3 (America/Santiago) and date is one of the few programs that gets it right.

timedatectl shows the following Time zone line: Time zone: n/a (UTC, +0000) Trying to set the time zone with timedatectl only fixes its own output (other programs still see whatever they want as timezone). After some minutes, timedatectl resets back to UTC+0 again.

Symlink tree for /etc/localtime: /etc/localtime -> /bedrock/run/localtime -> /bedrock/cross/zoneinfo/America/Santiago The time zone file itself looks fine to me.

It seems to be specific to my system, since I see no one else talking about this. What information should I provide about it? Here's my brl report as a start in case it helps.

[paradigm]

First, props for doing your homework and finding things like the symlink tree.

timedatectl insists /etc/localtime points into /usr/share/zoneinfo, despite every preexisting standard lacking this requirement. Bedrock can't make it happy and make /etc/localtime set the timezone consistently across all strata (which may have different local zoneinfo databases, or even lack any zoneinfo database at all).

/etc/localtime can be overridden by TZ, which would then let timedatectl do whatever it wants. However, Chromium has a TZ handling bug which hits derived programs, including Discord by way of Electron.

Bedrock's current strategy is to ensure TZ is unset to work around Chromium's bug. It (aggressively) set the timezone via /etc/localtime and just lives with timedatectl throwing a fit. Timezeone should be set with bedrock.conf and brl apply (as you did correctly). The fact Bedrock's current strategy does not play nicely with timedatectl absolutely should be documented on the website, but to my surprise appears to be absent. If I fail to include it in the upcoming website documentation rework, do feel free to remind me.

That explains timedatectl.

---

As for Discord being off by an hour, you're not the only one. Maybe try the Canary build?

---

Could you provide more information about what web browser you're using and how you're checking the time with it?

[SeerLite]

Could you provide more information about what web browser you're using and how you're checking the time with it?

Completely missed that! I'm currently having the issue on Vivaldi Browser and I am testing from this site (GMT=UTC, right?), but it affects all sites that use time zone information (like WhatsApp Web). I installed Chromium (both on Arch and Fedora) to make sure it wasn't just Vivaldi and I'm also getting UTC+0 there. So maybe the Chromium engine has problems with Bedrock?

Edit: No luck with Discord Canary :/ Discord package works fine on Arch, I'm using the same package/stratum on Bedrock, so I'm pretty sure it's Bedrock-specific.

[paradigm]

I can't trivially reproduce the issue with the browser. The provided link does indicate my timezone correctly in Arch's Chromium.

I also can't reproduce the issue with Discord. It works fine for me. I also know a number of Bedrock folks who use Discord who likely would have reported the issue to me (as they have in the past before the current timezone handling strategy).

It may be worth pointing out that Vivaldi, Chromium, and Discord all share a lot of code. There may be one underlying timezone bug here that you're just testing with different skins. Can you test in an independent program, e.g. Firefox? You should be able to test both the time website you've linked and discord's web page implementation with that.

I also noticed:

• Your timezone is in South America
• The previous read thread I linked pointed out the issue occurring in South America
• The latest /r/discordapp post that reddit's "timezone" search results find might also be from another South American.

Possible that's completely unrelated, but it's worth investigating, I think. Can you test with other timezones to see if the issue reproduces consistently on your system irrelevant of timezone, or if the issue is specific to your timezeone? For example, maybe America/Los_Angeles, which I'm guessing is the timezone where the Chromium devs that wrote the timezone handling code we're discussing live.

[SeerLite]

Alright, this is weird. I remember trying Firefox yesterday and it reporting the time correctly from the link, but now it's one hour behind too?

I might be misremembering again, but I feel like Firefox has been reporting the timezone right a few times, and wrong other times. I will continue as if it's always been wrong for now though, just in case it was because of me messing with timedatectl or something

So, both Firefox and Discord are reading the timezone as UTC-4, while Vivaldi and Chromium are reading it as UTC-0. This is when using America/Santiago.

Can you test with other timezones to see if the issue reproduces consistently on your system irrelevant of timezone, or if the issue is specific to your timezeone?

I changed my timezone to America/Los_Angeles, ran brl apply, and funnily enough all programs are showing this timezone correctly. It seems your suspicion was correct!

I still think this is Bedrock-specific though, because on Arch (same setup) these programs don't have this issue at all. (my btrfs snapshot of Arch really seems to be useful now, huh?)

What could the causing this? Is this reproducible for you by changing the timezone to something like America/Santiago?

[paradigm]

I haven't had the chance to reproduce this myself yet - I'm bouncing between a large number of support requests - but I have thought of something we could check.

Bedrock makes /etc/localtime a symlink that ultimately resolves into /bedrock/cross/zoneinfo as a way of ensuring all strata see the same exact timezone file. This way if some distros update their timezones earlier or later than others, at least the entire Bedrock system is consistent. Since you're not getting this consistency, we should probably sanity check this system.

Try running:

#!/bin/sh
for s in $(brl list); do
    printf "%s sees /etc/localtime provided by %s\n" $s $(strat $s brl which /etc/localtime)
done

This will show which stratum's timezone information each stratum sees. They should all be the same. If they're not, that'd explain your inconsistency.

If they're all arch, this debug avenue is a dead end. If they're not all arch, maybe they're being provided by a distro with a broken timezone database. In that case, try editing /bedrock/etc/bedrock.conf as root. Find the priority = field under the [cross] section and set it to prioritize whatever your arch stratum's name is, e.g. priority = arch. Once you've made that change and saved the file, run brl apply as root. Once that's done, re-run the above script to check everyone sees Arch's timezone information. Assuming that's the case, re-do the various test cases (date, firefox, etc).

[SeerLite]

Sadly, all strata use Arch's timezone info. The issue is something else entirely, probably related to how each program reads the timezone in a different way.

Still, thanks a lot! I'll try to investigate on my end this week if I can.

[paradigm]

I haven't forgotten about this; I've simply been swamped with many other issues.

I've been trying to find one timezone solution that works for everything, and in practice I'm not having any luck. Every strategy I try ends up triggering a bug in some program or another. While upstreaming fixes to every program that exhibits a timezone bug would be nice, the Bedrock developer resources aren't there.

The remaining option is to simply not have a one-size-fits-all solution. Have a default for most programs, then apply an alternative strategy for any program that shows up on a known list that are particularly picky. By happy accident, Bedrock already has infrastructure for such things, as it's essentially the same thing as restriction, just with different environment variables.

I'm not sure how long it will take me to get to it, but once I do you should be able to configure Bedrock to set Discord's timezone in any of a number of ways, one of which will hopefully work for you.

[Meister1593]

I'm currently experiencing similar issue but on hijacked void bedrock. Even with disabled arch strata (no timedatectl in PATH), my existing (before bedrock) flatpak chromium started using only UTC+0 time, instead of UTC+4. Same thing happens with arch's strata firefox Flatpak is installed in user folder, not system-wide Timezone is correct, and even date or ntptime shows proper time

brl report

[toast003]

I'm also having a similar issue, although this time on hijacked fedora I have both gnome clocks and calendar installed on fedora and discord canary on an arch strata, and for some reason both gnome clocks and discord work just fine and get the right time, while calendar crashes on startup. When I run in in a terminal I get this: (process:23679): GLib-CRITICAL **: 17:21:01.030: g_time_zone_get_identifier: assertion 'tz != NULL' failed

Here's my brl report.