Tracking timing and time-zone problems in QueueMetrics
2025-04-17It sometimes happens that a new QueueMetrics install has time-zone problems on a specific server.
Generally speaking, the local time for the QueueMetrics instance should be the same as your own
local time, and so should be for the MySQL server and the Asterisk server it relies on.
Small timing discrepancies can cause many problems, like calls not shown, wrong call duration and wait times on the realtime page, or even calls not showing at all on the realtime page.
If one of the clocks is very different from the current time (a few hours off, but the minutes/seconds appear to be right), it is usually a time zone problem on your server. This can usually be solved/detected running the following commands:
If everything seems correct and still the QueueMetrics server will insist on using the wrong time zone, you should try to force the correct Java time-zone id for your system:
If the timezone appears to be right, but DST changes were not applied at the right time, likey you have an outdated Java timezone database - the dates on which DST is applied are political decisions, so it is possible that the law was changed after your timezone database was generated. Updating your Java package to the latest minor release will make sure it is updated. Only update the minor release - do not blindly change the major Java version as QM might not work with it.
See also:
Small timing discrepancies can cause many problems, like calls not shown, wrong call duration and wait times on the realtime page, or even calls not showing at all on the realtime page.
To check which time QM and MySQL are using, the easiest thing for you to do is to check the License page.
Just click on the Licence page and the current clock and time zone for the QueueMetrics server and its MySQL instance will be shown. It's important that there is no difference between those values.
Generally speaking, the first thing you should do if you suspect a timing problem is run a command
that will sync the system clock with an high-precision atomic clock on all involved machines, for example:
ntpdate ntp.ien.it
As hardware clocks tend to "drift" in the long period, it is a good idea to add this command to a
nightly cron job that will keep the clocks of all involved systems below a one-second difference.
If one of the clocks is very different from the current time (a few hours off, but the minutes/seconds appear to be right), it is usually a time zone problem on your server. This can usually be solved/detected running the following commands:
[root@asterisk1 ~]# hwclock --show
[root@asterisk1 ~]# date -R
[root@asterisk1 ~]# date
[root@asterisk1 ~]# more /etc/sysconfig/clock
If everything seems correct and still the QueueMetrics server will insist on using the wrong time zone, you should try to force the correct Java time-zone id for your system:
- Set the TZ environment variable, like export TZ="US/Eastern" in the startup script you use for the QueueMetrics server, or
- Add the following option to the JAVA_OPTS environment variable: -Duser.timezone=US/Eastern
in the startup script you use for the QueueMetrics server - if you use a standard RPM install,
it will be usually at the beginning of /etc/sysconfig/qm-tomcat6.
For example, if you live in a place that is GMT+5, you could change the /etc/init.d/queuemetrics init script so that it has an options line like:export JAVA_OPTS="-Xms1G -Xmx1G -server -Duser.timezone=GMT+05:00"
If the timezone appears to be right, but DST changes were not applied at the right time, likey you have an outdated Java timezone database - the dates on which DST is applied are political decisions, so it is possible that the law was changed after your timezone database was generated. Updating your Java package to the latest minor release will make sure it is updated. Only update the minor release - do not blindly change the major Java version as QM might not work with it.
See also: