FS#34729 - [at] 3.1.13-2 daylight saving not working when time is given in utc
Attached to Project:
Community Packages
Opened by Tuomas Jäntti (qwertypoke) - Thursday, 11 April 2013, 09:45 GMT
Last edited by Balló György (City-busz) - Thursday, 23 May 2013, 02:09 GMT
Opened by Tuomas Jäntti (qwertypoke) - Thursday, 11 April 2013, 09:45 GMT
Last edited by Balló György (City-busz) - Thursday, 23 May 2013, 02:09 GMT
|
Details
Description:
If time is given as HH:MMutc the scheduled time will be in error by an offset of 1 in summer. Additional info: * package version(s) at 3.1.13-2 * config and/or log files etc. Steps to reproduce: # Helsinki time is utc+2 + 1 during summer [tuomas@rotta ~]$ date to 11.4.2013 12.22.24 +0300 # This is ok: [tuomas@rotta ~]$ ls | at now job 17 at Thu Apr 11 12:22:00 2013 # This is ok: [tuomas@rotta ~]$ ls | at 12:30 job 18 at Thu Apr 11 12:30:00 2013 # 9:30 utc should be 12:30 local time. # This does not work as intended: [tuomas@rotta ~]$ ls | at 9:30utc job 19 at Fri Apr 12 11:30:00 2013 [tuomas@rotta ~]$ atq 17 Thu Apr 11 12:22:00 2013 a tuomas 18 Thu Apr 11 12:30:00 2013 a tuomas 19 Fri Apr 12 11:30:00 2013 a tuomas The upstream package is in Debian: http://packages.qa.debian.org/a/at.html and the bug is also reported: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=364975 The bug fixes are not applied because the package seems to be currently unmaintained. If the package is not maintained and contains bugs, should it be removed from the Arch repository? If the package is patched downstream should it be moved to AUR or could the patches be applied to the Arch reposity package? Workaround for bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=364975#29 |
This task depends upon
Comment by Eric Belanger (Snowman) -
Wednesday, 17 April 2013, 18:48 GMT
As gnome-schedule is the only package in the repo which depends on
'at', I moved 'at' to community repo and reassigned the bug to
gnome-schedule's maintainer.
Comment by
Balló György (City-busz) - Monday,
20 May 2013, 23:52 GMT
I think that this bug is not critical, so we can keep 'at' package
in the official repositories. However, I don't want to patch the
package, because none of the available patches are reviewed by
upstream developers, and may cause regressions.