I've tried eliminating many of the common errors, 1) ensuring that the PATHs are available for cron2) there is an endline at the end of crontab file3) the timezone is set-up by:cd /etccp /usr/share/zoneinfo/Asia/Singapore /etc/localtimerunning date in bash, I get:Tue Sep 17 15:14:30 SGT 2013in order to check if cron is using the same time,* * * * * date >> date.txtis giving the same date output in date.txt.   This is the script I'm trying to execute:[event.sh]#!/usr/bin/env bashecho data > /root/data.txtusing crontab -e, the line below works, * * * * * /bin/bash /root/event.sh >/tmp/debug.log 2>&115 * * * * /bin/bash /root/event.sh >/tmp/debug.log 2>&1however, when i tried some other arguments, hoping it would run at 2.50pm:50 14 * * * /bin/bash /root/event.sh >/tmp/debug.log 2>&1or50 14 * * * (cd /root ; ./event.sh >/tmp/debug.log 2>&1)it will no longer work. Seems like there is a problem with my hour argument. Nothing could be found in the /tmp/debug.log file either.SOLUTION:it turned out i have to restart the cron service after making changes to TZ.
Cron job does not fire up after a timezone change
cron;timezone
First off, the odds that you are hitting a bug that causes one field to be incorrectly considered seems exceptionally low. It's more likely to be a misunderstanding of what's going on and what cron expects.In this case, we found out in the comments to the question that it was very likely a timezone related issue. For this, you would:Add an entry like * * * * * date to the crontabRemove (or comment out) any TZ assignment from the crontabThis forces date to run with the time zone setting of the invoker, which means the cron daemon. Look at the output; it will show what time zone cron is using internally, and thus highly likely which time zone it wants its time fields in. If you have a TZ assignment in the crontab, it is easily possible that the TZ environment variable assignment is passed through to the invoked commands but cron itself uses some other time zone. By commenting out or removing the TZ assignment, you avoid this ambiguity.Also note that any changes to the system global timezone settings (including e.g. /etc/localtime) almost certainly require at least a restart of the cron daemon, and possibly (though unlikely) a system reboot to take full effect. Editing the TZ assignment in the crontab should not require a reload of the cron daemon, as it should detect that the file has been changed and reload it automatically.