Page 1 of 1

ViciBox Time Issue

PostPosted: Tue Jan 25, 2011 1:36 pm
by Geil21
ViciBox_Redux.i686-3.1.5
VERSION: 2.4-296
BUILD: 110111-1305
© 2011 ViciDial Group

Fresh Install on Pentium Dual Core System With 2 Gigs Ram and 7 seats
Digium TDM2400 Analog Board For Internal FXS/FXO and SIP for Outbound

Upgraded GoAutoDial Asterisk Database From 2.2 to 2.4

The system clock shows the correct time and time zone

The web interfaces are off by 3 hours, any idea for cause?

On the real time screen 180 minutes are added to the Wait/Ready/Pause Times

Reporting shows accurate call lengths, but interval report is off by 3 hours as well

Server GMT is -5.00 (Eastern)
Phone are set at -5.00 (Eastern)[/u]

PostPosted: Tue Jan 25, 2011 2:06 pm
by williamconley

PostPosted: Tue Jan 25, 2011 4:07 pm
by Geil21
Thanks Bill,

I'll try it tonight

PostPosted: Wed Jan 26, 2011 1:42 am
by Trying
I can testify that the fix works :)

PostPosted: Wed Jan 26, 2011 11:39 am
by Eugene
By the way, setting default timezone in php.ini for apache has an interesting by-effect. Say, agent gui shows current OS time correctly, and management gui shows shifted current time. And agent time in his current state is shown as actual time + that shift in both guis.

PostPosted: Wed Jan 26, 2011 11:53 am
by williamconley
perhaps you should be more specific. ya lost me with "shifted current time", "current state" and "both guis".

PostPosted: Wed Jan 26, 2011 3:52 pm
by Eugene
Thank you for the lesson! I should be more careful with my English.

Ok. We use agent's gui and it shows time which is the same as OS shows. When we open administrator's gui it shows time being different from OS time. The difference 'shift' is the difference between time zone set in OS and default time zone set in php.ini.

There is 'main realtime report' in the administrator's gui. One of the columns in the report shows amount of time which says how long an agent is in his current state, namely, paused, waiting for a call, etc.

That 'amount of time' field can be seen in agent's gui as well, if enabled to be shown in 'View Agents' sidebar.

In both cases ('in both guis' :oops:), that amount of time is the sum of actual time period and the difference between timezones mentioned above.

PostPosted: Wed Jan 26, 2011 4:20 pm
by williamconley
difference between time zone set in OS and default time zone set in php.in
why are they different?

PostPosted: Wed Jan 26, 2011 4:38 pm
by Eugene
why are they different?

I do not know. Probably ViciBox web server setup does that. Interesting, that ViciBox 3.1.5 had 10 hours timezone offset and 3.1.6 had 7 hours offset 'by defalt', i.e. after fresh install. (I am in GMT+2 zone)

I had to comment out default time zone in php.ini to make php use OS clock.[/quote]

PostPosted: Wed Jan 26, 2011 4:46 pm
by williamconley
perhaps you could ... change the time zone to the correct value?

http://www.vicidial.org/VICIDIALforum/v ... hp?t=15461

PostPosted: Thu Jan 27, 2011 2:43 am
by Eugene
perhaps you could ... change the time zone to the correct value?

My OS timezone is correct and OS time is in sync with trusted NTP servers.
http://www.vicidial.org/VICIDIALforum/v ... hp?t=15461 has a quote reading
It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting

That statement is very surprising to me. What could be trusted if not OS settings? I could understand that it was not safe to rely on the current php date() implementation and it was required to set default timezone in php.ini to use it flawlessly. That would be fine explanation.

Well, probably there might be another reasons to set php timezone. But without an explanation I find it hard to believe that I should not let php to use OS settings.

PostPosted: Thu Jan 27, 2011 8:41 am
by williamconley
since you are not likely to CHANGE the time zone in which you reside, and the time zone for php.ini will then only be set ... Once, setting it to match the OS time zone is fairly easy and a one-time operation.

But for security purposes they are apparently unsure that someone could not find a way (or SURE that someone already has) to manipulate the php time and use that as a method to exploit your system (unless you lock the setting by placing it directly into php.ini). ordinarily when this sort of statement is made, there is a safety reason involved and it should not be ignored. especially when the resolution is this simple.

The group working on php in this area and all other areas of all the other packages make decisions all the time. I'm not going to second guess all of them and micromanage a server to that extent. If the "Best Practices" instruction from the team working on that package say "set php.ini to the proper timezone ..." i'm not sure it's worth arguing about. :)