Bug 435765

Summary: at reschedules jobs inconsistantly when dst begins or ends
Product: [Fedora] Fedora Reporter: Ali Corbin <ali_corbin>
Component: atAssignee: Marcela Mašláňová <mmaslano>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: mcepl, mcepl
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-01-12 10:00:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ali Corbin 2008-03-03 18:59:45 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12

Description of problem:
If you use a date with 'at' to schedule a job in the gap between 2am and 3am on the morning that daylight saving time begins, then at will reschedule the job for after 3am.  (This makes sense, since the hour between 2 and 3 doesn't exist on that day.)

But if you use a day of the week with at, it will schedule the job an hour earlier, between 1 and 2.

> date
Mon Mar  3 10:19:39 PST 2008
> at -f ./attest 0230 Mar9
job 29 at Sun Mar  9 03:30:00 2008
> at -f ./attest 0230 sunday
job 30 at Sun Mar  9 01:30:00 2008

Something similar also happens in the fall:

> at -f ./attest 0230 Nov2
job 31 at Sun Nov  2 02:30:00 2008
> at -f ./attest 0230 sunday + 34 weeks
job 32 at Sun Nov  2 01:30:00 2008



Version-Release number of selected component (if applicable):
at-3.1.10-19.fc8

How reproducible:
Always


Steps to Reproduce:
1. echo "date >> /tmp/xxx" > attest
2. set the date to be the week before Mar 9, 2008
3. at -f ./attest 0230 Mar9
4. at -f ./attest 0230 sunday

Actual Results:
job 29 at Sun Mar  9 03:30:00 2008
job 30 at Sun Mar  9 01:30:00 2008


Expected Results:
job 29 at Sun Mar  9 03:30:00 2008
job 30 at Sun Mar  9 03:30:00 2008


Additional info:
Granted, this is an obscure problem that will only occur in two hours of the year.

I'm not even sure that rescheduling jobs that fall into the DST gap an hour later is the proper thing to do.  I would think, however, that all jobs should be rescheduled the same way, regardless of the format used to specify the time and date.

Comment 1 Matěj Cepl 2008-11-28 17:16:12 UTC
There is nothing to triage here (and one cannot underestimate importance of this bug for the further development of the Open Source movement).

Switching to ASSIGNED so that developers have responsibility to do whatever
they want to do with it.

Comment 2 Marcela Mašláňová 2009-02-27 08:49:39 UTC
I see you are interested in at from other bug reports. I'm aware of those problems. I have tried track down this problem in grammary of at but no luck yet. It looks like days are counted correctly. Patches are welcome. The other bug #478644 will be probably close this one. Maybe the conception of at didn't count with these things at all.

Comment 3 Marcela Mašláňová 2012-01-10 14:48:21 UTC
With at-3.1.13

[root@localhost ~]# date -s 20120325
Sun Mar 25 00:00:00 CET 2012
[root@localhost ~]# at 0230 sunday
at> echo a
at> <EOT>
job 15 at Sun Apr  1 03:30:00 2012
[root@localhost ~]# at 0230 Mar 25
at> echo a
at> <EOT>
job 16 at Sun Mar 25 03:30:00 2012

So, now it jumps month forward, but only when that day is DST.

Comment 4 Marcela Mašláňová 2012-01-12 10:00:35 UTC
at 15:00 thursday
at> echo bb
at> <EOT>
job 17 at Thu Jan 19 15:00:00 2012
[root@localhost ~]# at 3:00 thursday
at> echo bb
at> <EOT>
job 18 at Thu Jan 19 03:00:00 2012
[root@localhost ~]# date
Thu Jan 12 10:59:04 CET 2012

So, everytime when name of the day is used, then it's the next week, not today.

The reported bug was fixed in at-3.1.13.