timezone offset issues primarily in qtwebenine

  • Open
  • quality assurance status badge
Details
One participant
  • divan
Owner
unassigned
Submitted by
divan
Severity
normal
D
(address . bug-guix@gnu.org)
873698jwq8.fsf@swift.i-did-not-set--mail-host-address--so-tickle-me
Greetings :)

Having similar issues to https://issues.guix.info/issue/35746but not
quite the same.

I'm having time offset issues in various applications on guix system.

My timezone is set to

(operating-system
(host-name "swift")
(timezone "Africa/Johannesburg")
(locale "en_US.utf8")

Which in terminal is correct
ds@swift ~ $ date
Sun 12 Apr 2020 09:54:27 PM SAST

So I'm +0200, yet many applications report there time in UTC which is
frustrating.

Apps being:
- qutebrowser
- ungoogled-chromium

icecat works, when the privacy feature (ResistFingerprinting) is
disabled in about:config .

I was chatting to the maintainer of qutebrowser, str1ngs, on #guix and
he did not have the same issue on his guix system. Which is really
strange. He tried various debugging with me and in the end I think he
said:

<str1ngs> divansantana and QDateTime works as well [21:12]
<str1ngs> it's something qtwebenine or javascript related

My locale, in case that's relevant:

$ locale
LANG=en_US.utf8
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=

I test the browser timezone via browsing to https://play.grafana.org/
for instance. But I've noticed the issue in multiple sites.

Perhaps this is a separate issue but in notmuch I notice similar:

In some emails it gives time in UTC
Date: Thu, 09 Apr 2020 12:55:21 +0000

While other emails it gives +0200 time.
Date: Sun, 12 Apr 2020 21:04:01 +0200
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 40585@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 40585
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch