I’m running the 1.0.988 firmware, and my Vera doesn’t have this problem, so you might be able to fix the problem by upgrading to the newer firmware. Then again, I didn’t have this problem when I was running 1.0.979 either.
So given what you’ve posted, it sounds to me like Vera still believes you’re on some other timezone than you do. Unix/Linux time-service stuff tries to “nudge” the time to what it should be, rather than doing it all at a wallop…this is done mostly to avoid creating big time discontinuities for services, logs, etc on the box. I suspect if you looked closer, you’d find that it’s actually nudging things a few seconds every minute, crawling towards what it believes to be the truth.
If you go in through the web GUI, what does it show for your timezone? Is it what you expect? If not, change it–brute-force changing the time without fixing the timezone would give you very much the behavior you’re seeing on any Linux box I’ve worked with that was running a NTP client.
I do not believe it thinks I am on a different time zone.
After I did the upgrade a couple of days ago, I set it up to the correct time zone, with correct time being displayed in the LOCATION tab.
Some days later is when I noticed the time difference.
Even after I brute-force the time using the date command, it loses 5 minutes per half hour.
Nothing to do with the time zone here I think. Some can say it’s because VERA does not have an internal hardware clock. I still think my unit is [profanity redacted] up, or the kernel was not compiled with -nopic or some other funky options…
as rlmalisz said, this is typical behavior when the NTP (network time protocol) has some ideas and you brute-force something else. First you have to figure out what is it trying to do, and why.
check “[tt]date -u[/tt]” and “[tt]date -R[/tt]”. The first one should show UTC time, and the second one shows local time in a more ‘regular’ format, where the timezone is expressed as a number and not by name.
Remember that the internal clock works on UTC time and NTP synchronizes only that. The localtime is converted each time to show using the timezone info. If it somehow got a bad definition of ‘EST’, or if it’s wrongly applying summer time, or anything else…
root@HomeControl:~# date
Fri Mar 5 18:09:07 EST 2010
root@HomeControl:~# date -u
Fri Mar 5 23:09:09 UTC 2010
root@HomeControl:~# date -R
Fri, 05 Mar 2010 18:09:10 -0500
it’s all good…
I will stop the ntpclient in crontab and see what happens again…