diff options
author | ivanbrennan <ivan.brennan@gmail.com> | 2020-11-02 07:31:03 -0500 |
---|---|---|
committer | jao <jao@gnu.org> | 2020-11-02 17:57:40 +0000 |
commit | a58e32f7c8af7b03410ab6693019cfc92c9cfca3 (patch) | |
tree | 66e37c1d3bfc567c911fb2a29ee3c3c3ee5df8a2 /src/Xmobar/System/Utils.hs | |
parent | cce1205c4915384746ba9347974c9501a01b395a (diff) | |
download | xmobar-a58e32f7c8af7b03410ab6693019cfc92c9cfca3.tar.gz xmobar-a58e32f7c8af7b03410ab6693019cfc92c9cfca3.tar.bz2 |
Revert "Optimize date plugin"
This reverts commit 878db39080607ba476ba8d8f547ad28259efb6a9. That
commit optimized the date plugin by avoiding calling getTimeZone on each
execution, instead calling it just once upon startup and reusing that
zone. As a result, the time zone will not be updated dynamically, e.g.
when shifting in or out of daylight savings time.
I noticed this after my local time zone had shifted from EDT to EST. My
xmobar showed 4:30 when the local time was in fact 3:30 (and running
date on the command line confirmed that my system clock was actually
aware of this shift). I had to restart xmobar in order to pick up the
new time zone.
I repro'd the unexpected behavior by temporarily disabling my system's
time syncing, setting the time to 30 seconds before the zone shift,
running date to confirm I'd set the correct time, restarting xmobar, and
observing.
sudo systemctl stop systemd-timesyncd.service
date --set="01:59:30"
date
I observed my xmobar clock go from 1:59 to 2:00, rather than from 1:59
to 1:00 as expected.
Following the same steps, I was able to verify that this commit fixes
the issue.
Diffstat (limited to 'src/Xmobar/System/Utils.hs')
0 files changed, 0 insertions, 0 deletions