# cron runs in UTC time not local time



## dragonbite (Nov 27, 2012)

(_first off, "Hi", this is my first post here though I am active in a few Linux forums_):beer

I have a FreeBSD 8.2 web server that a co-worker set up.  I am trying to get cron to run a script I have which takes a text file (a database query uploaded by another server) and puts the data in the proper PostgreSQL database, emailing me if there are any errors.

What I have found is cron is running on UTC time, not local time. So setting the crontab to run at 5:30 AM results in it running 5:30 UTC, or 12:30 AM local time.  This ends up updating the database before the new text file is uploaded!

Is there a way to have it run based on local time either for [1] the specific job, [2] specific user or [3] globally?

I could take the cron job and set it to <desired time> + 5 but then there is daylight savings time and coordinating to make sure the other server uploads the text file early enough to handle the fluctuation.

Thanks for any help!


----------



## Beeblebrox (Nov 27, 2012)

Read adjkerntz(8)() and also show your relevant entries to /etc/crontab.

```
# Adjust the time zone if the CMOS clock keeps local time, as opposed to
# UTC time.  See adjkerntz(8) for details.
1,31    0-5     *       *       *       root    adjkerntz -a
```
That means you would probably have to disable this.


----------



## dragonbite (Nov 27, 2012)

The adjkerntz(8) page states 





> If the file /etc/wall_cmos_clock exists, it means that CMOS clock keeps local time (MS-DOS and MS-Windows compatible mode).  If that file does not exist, it means that the CMOS clock keeps UTC time.



I took a look and /etc/wall_cmos_clock exists, so the CMOS clock should be keeping local time

My current time shows 
	
	



```
$ date
Tue Nov 27 11:45:39 EST 2012
$ date -u
Tue Nov 27 16:45:41 UTC 2012
```

I've been trying different things, such as setting in crontab, but this didn't change anything 
	
	



```
TZ="America/New_York"
```
 I also tried TZ=EST but I am thinking this may be something Linux-related.

So the important bits of crontab are 
	
	



```
#Turn off automatic CRONTAB email and let the individual proccesses handle mailing.
MAILTO=""

# You can use $HOME to specify the home directory instead of the full path

# run update script 5:30 AM, messaging and mailing handled by script
30 5 * * * $HOME/updatedb.sh &>/dev/null
```

The code does work.


----------



## Beeblebrox (Nov 27, 2012)

> Tue Nov 27 11:45:39 EST 2012
> 
> Tue Nov 27 16:45:41 UTC 2012



Separate issue (maybe not) but, the two times are (41-39) 2 seconds apart. You should add ntpd to the rc.conf and configure ntp.conf.

You *do* realize that the CMOS clock should be set to UTC and that the system will take care of <localtime>? If you decide to "convert" you will need to reset the CMOS to UTC time in BIOS setup and then make the adjustments to system (# sysinstall will help you here). Please google that, because I don't know which one should be done first.


----------



## mamalos (Nov 27, 2012)

beeblebrox, the 2 seconds skew are probably because it took OP 2 seconds to run the second date(1) command. It is not rational to have different *seconds* on your locatime with respect to UTC, since the difference granularity between them is counted in hours. NTP is a different matter, unrelated to this time skew.


----------



## Beeblebrox (Nov 27, 2012)

@dragonbite: is/was ntpd running?


----------



## dragonbite (Nov 27, 2012)

The clock is set by ntpd according to the system administrator, but he doesn't know why cron is using UTC time instead of local time (he thought cron runs local time by default).  

I am not sure how to check/verify ntpd is running (would that be under "top" or "modprobe"?)


----------



## Beeblebrox (Nov 27, 2012)

> # sysinstall will help you here


Well you see: # sysinsall then -> Index -> Time Zone  will give you.


> Is this machine's CMOS clock set to UTC?  If it is set to local time,â”‚
> â”‚ or you don't know, please choose NO here!


Look in you BIOS CMOS clock. If it is *NOT* set to UTC; then there are more problems that you are aware. Otherwise you can modify the BIOS CMOS to UTC and convert everything to "proper".
WARNING: A good "conversion" has steps and I did not take notes so you need to look that up.


----------



## t1066 (Nov 28, 2012)

Maybe tzsetup() is what you want.


----------



## Beeblebrox (Nov 28, 2012)

@t1066: You are right, I misread this:


> such as setting in crontab, but this didn't change anything TZ="America/New_York"


@dragonbite: Crontab has nothing to do with time zones.


----------



## dragonbite (Nov 28, 2012)

Thank you all for your patience.

I am not sure how changing the CMOS clock to UTC will change CRON to using Local time.  

When I ran tzsetup and selected "No" it went through asking for my time zone but that has already been set up to EST (as the date output shows).  

Would selecting "Yes" change that to CMOS and would it then throw the local date out of whack because instead of it being 14:35 UTC (9:35 local) it would be 9:35 UTC (4:35 local)?

I'm sorry, I just don't see the thought process.


----------



## Beeblebrox (Nov 28, 2012)

Did you read adjkerntz(8)() ?


> The adjkerntz utility maintains the proper relationship between the kernel clock, which is always set to UTC, and the CMOS clock, which may be set to local time.
> 
> If the file /etc/wall_cmos_clock exists, it means that CMOS clock keeps local time. If that file does not exist, it means that the CMOS clock keeps UTC time.  The adjkerntz utility passes this state to the machdep.wall_cmos_clock kernel variable.


I think it would be worth your effort to fully look into how this command / utility works.


----------



## wblock@ (Nov 28, 2012)

I've always used local time for both, and figured tzsetup(8) did everything necessary.  No problems noticed.


----------



## dragonbite (Nov 28, 2012)

> The adjkerntz utility maintains the proper relationship between the kernel clock, which is always set to UTC, and the CMOS clock, which may be set to local time.



I see two options that either synchronizes from local to UTC ( -i)  or UTC to local ( -a). I already have adjkerntz installed and running in the crontab (code below), updating the local time from the kernel (UTC) time and adjusting for daylight savings time.  


```
# Adjust the time zone if the CMOS clock keeps local time, as opposed to
# UTC time.  See adjkerntz(8) for details.
1,31    0-5     *       *       *       root    adjkerntz -a
```

It also appears that since adjkerntz is running that the kernel clock is running UTC. 





> The adjkerntz utility clears the kernel timezone structure and makes the kernel clock run in the UTC time zone.



So if I remove adjkerntz then the kernel clock could be running local time instead of UTC, and that is the time cron uses?  Is that what you are thinking?


----------



## t1066 (Nov 29, 2012)

Just two questions.

What does

`$ ps aux | grep adjkerntz`

show and when did the daily security check run?


----------



## dragonbite (Nov 29, 2012)

t1066 said:
			
		

> Just two questions.
> 
> What does
> 
> ...



`$ ps aux | grep adjkerntz`
did not return anything.  If I run it a second time it just shows me grepping for it.

I am not sure, what you mean by "daily security check"?


----------



## t1066 (Nov 30, 2012)

My system shows


```
$ ps aux | grep adjkerntz
root         169   0.0  0.0    9920      0 ??  IWs  -            0:00.00 adjkerntz -i
$ ps aux | grep cron
root        1425   0.0  0.0   14124    408 ??  Is   14Oct12      0:22.96 /usr/sbin/cron -s
```

You would notice that adjkerntz start earlier than cron. Maybe you can run

`# service adjkerntz restart`

to see if this will solve your problem.

By security check, I mean the two emails that root receive daily.


----------



## dragonbite (Nov 30, 2012)

Thank you all!  It appears to have been solved!

I was looking online and ran across this thread : http://forums.freebsd.org/showthread.php?t=18780 and the last line gave me an idea so I tried it.

I restarted crond with 
	
	



```
/etc/rc.d/cron restart
```

I don't know if the cron job last started when the server was all-UTC and now that the timezone is established and it was restarted it is grabbing the local time, or what.

Thank you for your patience and your help. My apologies if this was suggested before and I didn't understand or it didn't hit me (sometimes I need a baseball bat in the side of the head).

Either way this has been a learning experience.  Now I have to figure out how to mark this thread as solved.


----------



## _martin (Feb 6, 2013)

dragonbite said:
			
		

> I restarted crond with
> 
> 
> 
> ...



Doh! I had this issue now and I was not able to figure out why was cron behaving the way it was - everything is set properly and yet cron was executing scripts in weird time (+1h as I am GMT+1). I guess sometimes _did you try to turn it off and on again_ is the way to go


----------



## dragonbite (Feb 7, 2013)

That's part of Microsoft's 4 "R"s of troubleshooting...

"R"estart the application
"R"estart Windows
"R"einstall the application
"R"einstall Windows

and my preferred fourth "R"

"R"eplace Windows with something else!


----------



## _martin (Feb 7, 2013)

dragonbite said:
			
		

> "R"eplace Windows with something else!



 .. but over these years I can tell you sometimes I'd rather see Windows server than Linux one (preferably HPUX/Solaris/FreeBSD though). But not to start a flame or anything; my opinion only.

This cron thing is weird. I did a setup of this server at home, synced all pools and later moved it to DC. There were several reboots (power offs) of this server with a proper timezone set (and clock was always UTC). So I don't get it why actually restart of the cron helped. I guess I'll find out next downtime I'll have.


----------

