Bug 223662

+++ This bug was initially created as a clone of Bug #222464 +++

Description of problem:
crond failed to decode "Days of week" entry within crontab 
after 1st system reboot of 1st/Jan. 2007. 
System started to run different "days of week" entry of the crontab.
(example: 2 days ago.)

Version-Release number of selected component (if applicable):
Affected: vixie-cron-4.1-10 and vixie-cron-4.1-11
NOT affected:  vixie-cron-3.


How reproducible:
Always reproducible the system clock is set after 1st of Jan. 2007.
AND crond is started after 2007.

If the system clock is set before 1st/Jan. 2007, it never happened.
If the crond never re-started after 2007, it never happened.

Steps to Reproduce:
1. Create crontab entries.

* * * * 0 date >> /tmp/sun.txt
* * * * 1 date >> /tmp/mon.txt
* * * * 2 date >> /tmp/tue.txt
* * * * 3 date >> /tmp/wed.txt
* * * * 4 date >> /tmp/thu.txt
* * * * 5 date >> /tmp/fri.txt
* * * * 6 date >> /tmp/sat.txt
* * * * 7 date >> /tmp/sun.txt

* * * * sat date >> /tmp/sat_sat.txt

2. Set the system time to  12/31  23:50, 2006.
# date 123123502006

3. Check /tmp. (It is now 23:51, 12/31, 2006.)
   /tmp/sun.txt is written. (This is expected.)

4.  Wait until  1/1 00:05,  2007.
   
5. Check /tmp (It is now 1/1 00:06, 2007)
   /tmp/mon.txt is written. (This is expected.)

6. Restart crond.
   # /etc/init.d/crond restart

7. Check /tmp  (It is now 1/1 00:08, 2007)
   
   Actual results:
   /tmp/sat.txt and /tmp/sat_sat.txt are written.

   Expected results:
   /tmp/mon.txt should be written.

I confirmed multiple system encountered same symptom 
with this steps.

Additional info:

System IA32(Intel)
kernel 2.4.21-32.0.1
tzdata-2006m-3.el3
vixie-cron-4.1-10.EL3

# rpm -qa |grep glibc
glibc-utils-2.3.2-95.27
glibc-headers-2.3.2-95.27
glibc-2.3.2-95.27
compat-glibc-7.x-2.2.4.32.6
glibc-common-2.3.2-95.27
glibc-devel-2.3.2-95.27
glibc-profile-2.3.2-95.27
glibc-kernheaders-2.4-8.34.1

FYI. 
I don't see this symptom on my private FC5.

-- Additional comment from masanari_iida on 2007-01-15 01:02 EST --
Narrow Down the problem....

(1) The symptom occured a crond restarted between Jan 1st 0:00AM - 9:00AM, 
any year.

FYI,  the test environment has TZ=JST-9. 

(2) If you don't restart crond between the period, nothing may happen.

(3) Once you see the symptom, restart the crond AFTER Jan 1st 9:00AM may 
fix the problem.

[How to reproduce]

(0)  Confirm your local time zone.
# more /etc/sysconfig/clock
ZONE="Asia/Tokyo"
UTC=false
ARC=false

(1)  date 010108572003 
(2)  /etc/init.d/crond restart   
(3)  Confirm mon.txt is exist under /tmp. 
This is wrong file, because 1st/Jan, 2003 is Wednesday.

# ls -l
-rw-r--r--    1 root     root           29 Jan  1 08:58 mon.txt

# date
Wed Jan  1 08:59:17 JST 2003

(4) After 9:01(AM), you restart the crond.
# /etc/init.d/crond restart

(5) Confirm which file is used.
-rw-r--r--    1 root     root           29 Jan  1 09:03 wed.txt　
-rw-r--r--    1 root     root          145 Jan  1 09:02 mon.txt　　

mon.txt is used _BEFORE_ the crond restarted.  (Wrong file)
_AFTER_ crond restart in step 4, wed.txt is used. (Correct file)






-- Additional comment from masanari_iida on 2007-01-16 05:35 EST --
Test on RHEL4 + vixie-cron-4.1-20_EL, follow the comment #1 step-by-step.
I have confirmed the same problem exist on RHEL4.


-- Additional comment from krafthef on 2007-01-18 11:00 EST --
this came in late for 3.9; moving to 4.6

-- Additional comment from yves.begrand on 2007-01-19 13:30 EST --
This would likely fix the problem:

--- vixie-cron-4.1/misc.c.new-year	2007-01-19 12:19:26.000000000 +0000
+++ vixie-cron-4.1/misc.c	2007-01-19 13:50:22.000000000 +0000
@@ -748,7 +748,7 @@
 	if (local->tm_year < gmt.tm_year)
 		offset -= 24 * 3600;
 	else if (local->tm_year > gmt.tm_year)
-		offset -= 24 * 3600;
+		offset += 24 * 3600;
 	else if (local->tm_yday < gmt.tm_yday)
 		offset -= 24 * 3600;
 	else if (local->tm_yday > gmt.tm_yday)

Thanks,

Yves.