Browser reports wrong timezone

[Galicarnax]

Version info: qutebrowser v3.1.0 Git commit: 57d609cc9-dirty on master (2024-04-29 10:22:55 +0500) Backend: QtWebEngine 6.7, based on Chromium 118.0.5993.220, with security patches up to 122.0.6261.128 (plus any distribution patches) (from api) Qt: 6.7.0

CPython: 3.12.3 PyQt: 6.7.0

Qt wrapper info: PyQt6: success PyQt5: not imported -> selected: PyQt6 (via autoselect)

colorama: no jinja2: 3.1.3 pygments: 2.17.2 yaml: 6.0.1 adblock: no objc: no PyQt6.QtWebEngineCore: 6.7.0 PyQt6.sip: 6.7.12 pdf.js: no sqlite: 3.45.3 QtNetwork SSL: OpenSSL 3.2.1 30 Jan 2024

Does the bug happen if you start with --temp-basedir?: yes

Description

The region where I live had advanced the clock forward by one hour on March 1, 2024 (not related to summer time; it was a single-shot event, to unify things across the country). So now I am in UTC+05:00, wheres before that I was in UTC+06:00. The system clocks on all my Linux hosts automatically switched, as that change was already reflected in the appropriate packages prior to that. Yet, qutebrowser continued to use old timezone. I guess this has to do with qt6 webengine. Issuing new Date() in devtools already reports wrong timezone. I'm not sure why it uses its own definitions of timezones rather than system ones (btw, Firefox and Google Chrome show correct timezone). I hoped it would update its definitions soon, but it's already two months, and even after recent update of webengine to v. 6.7.0, I'm still in wrong timezone with my browser. Is there a way to force the engine to change its timezone?

[The-Compiler]

It's indeed likely that qutebrowser can't do anything about this. I'd be happy to take a cursory look at this anyways, but I'd need to know how to reproduce this. In other words:

• What does locale say?
• What does timedatectl say (or whatever else you use to set your system-wide timezone)?
• What does new Date() in qutebrowser say?
• What would you expect instead, i.e. what does new Date() say in e.g. Google Chrome?

[The-Compiler]

Ah, found the details via your GitHub profile.

According to Kazakhstan timezone changes (Mar 1, 2024) are not reflected in Intl.DateTimeFormat (IANA 2024a) [327475245] - Chromium, this was fixed in Chromium 122, but Qt 6.7 is based on Chromium 118. Thus, this would only normally arrive with Qt 6.8, scheduled for September. I'll ask in the QtWebEngine IRC if they'd be willing to backport the patch, but nothing more qutebrowser can do here.

[The-Compiler]

As for:

I'm not sure why it uses its own definitions of timezones rather than system ones

Chromium seems to use the data from ICU. QtWebEngine can be built against the system ICU (and many distributions, e.g. Archlinux, do so). It seems you installed Qt/QtWebEngine in a way that bundles ICU.

[Galicarnax]

Thanks for clarifying the issue. I'm just left wondering why wouldn't the engine use (or even allow to use) host system settings for that...

UPD: Oh, you already answered :)

[The-Compiler]

The settings aren't the problem, the underlying data (tz, which gets vendored in ICU, which optionally gets vendored in QtWebEngine/Chromium) is.