summaryrefslogtreecommitdiffhomepage
path: root/examples
diff options
context:
space:
mode:
authorivanbrennan <ivan.brennan@gmail.com>2020-11-02 07:31:03 -0500
committerjao <jao@gnu.org>2020-11-02 17:57:40 +0000
commita58e32f7c8af7b03410ab6693019cfc92c9cfca3 (patch)
tree66e37c1d3bfc567c911fb2a29ee3c3c3ee5df8a2 /examples
parentcce1205c4915384746ba9347974c9501a01b395a (diff)
downloadxmobar-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 'examples')
0 files changed, 0 insertions, 0 deletions