Call times don't follow DST changes

[ddsDave]

When we switched to BST from GMT over the weekend the call time bands we have defined did not follow the change and are now an hour out. As a quick fix I've redefined the times, but that's hardly a correct solution. How do I associate a call time definition with a timezone in such a way that it follows DST changes?

[enjay]

Does your server have the correct timezone set on it?

-Art

[ddsDave]

Yes, the server timezone is correct and the server time did adjust for the DST change.

[mflorell]

Did you reboot your servers after making the change?

VICIDIAL goes of of the timezone details and DST details that perl/PHP send it(along with the settings in the servers and phones tables). If the server is not rebooted, or every application restarted, you may still be using the old timezone definitions on those applications.

[ddsDave]

Why would I do that? DST changes are automatic.

[albatroz]

What should be correct timezone for the server?
GMT?

Does your server have the correct timezone set on it?

-Art

[ddsDave]

GMT

[mflorell]

DST changes are not automatic for all applications, as some of us in the US found out with our DST change this year. Some programs will not reload the Timezone information after they are launched.

[albatroz]

I put in the BIOS of my server the GMT time, but VICIDIAL shows as the customer's time a different one. I would like to know how is it calculated...

[mflorell]

what does PHP show as isdst()?

What does perl show the time() command output?

[ddsDave]

There doesn't seem to be a isdst() function in PHP? phpinfo() says

date/time support enabled
Timezone Database Version 2006.1
Timezone Database internal
Default timezone Europe/London

I dont know perl so I dont know how to display the time() value.

[mflorell]

Sorry about that, internal function.

For php use:

<?
echo date("I");
?>

For perl use:

#!/usr/bin/perl
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);
print "$isdst\n";
exit;


If they output 1 then they think you are in DST.

[ddsDave]

Both return 1.

[mflorell]

That means that both of them still think that your machine is set to a time zone that observes DST and they are changing the hour accordingly.

[albatroz]

In my case also returns the value 1, what does it mean?

[ddsDave]

But I *AM* in a time zone that observes DST & it is the DST period. That's the point. The server (along with everyone else) switched to DST correctly, only ViciDial's "Dial Time" definitions stayed relative to GMT/UCT & didn't adapt.

[mflorell]

What version of astguiclient?

Did you upgrade from an earlier version?

[albatroz]

These are my versions:

VICIDIAL ADMIN
VERSION: 2.0.90 BUILD: 70302-1111

VICIDIAL WEB CLIENT
VERSION: 2.0.122 BUILD: 70226-1252

I put in the BIOS of my server the GMT time, but VICIDIAL shows as the customer's time a different one. I would like to know how is it calculated...

[mcargile]

Seem to be having a similar problem with one of our clients in Denver. The system was put together about two weeks ago and has been having testing done on it. Today was the first day it was actually going to be put into service. Mind you the testing has only taken place in the afternoon.

Well this morning when they fired it up, the dialable lead count was wrong. Upon closer inspection someone had forgotten to take the system off the default GMT offset of -5 and put it on -7. I did so and rebooted the box. The leads are still messed up however.

The servers date command returns:
Wed Apr 11 09:09:36 MDT 2007

But when I go into the list it shows the local time for the various timezones wrong:
TIME ZONES WITHIN THIS LIST:
GMT OFFSET NOW (local time) CALLED NOT CALLED
-8.00 (Wed Apr 2007 07:09) 0 4707
-7.00 (Wed Apr 2007 08:09) 0 475
-6.00 (Wed Apr 2007 09:09) 2000 5092
-5.00 (Wed Apr 2007 10:09) 2875 0

I know that right now it is 11:09 on the East Coast (GMT -5).
the astguiclient version is 2.0.2

[mflorell]

What is the GMT offset and time zone of Linux set to on that machine?

What are the phones table GMT offset set to?

[mcargile]

the time zone MDT, the offset is -6, according to date. We set the GMT offset of the server to -6 after my last post. There are no phones just remote agents.

One issue I though of was that the leads have their GMT offset adjusted for DST because they populate the vicidial_list table themselves

[mflorell]

Did you run the ADMIN_adjust_GMTnow_on_leads.pl
after you changed timezones?

[mcargile]

We seem to be having trouble doing some math here. (been an interesting week)

The leads need to have the GMT offset without DST and the server needs the GMT offset without DST as well.

So if the server is on the US East Coast the servers GMT offset would be -5 and a lead on the US East Coast would have an offset of -5 as well? I.E. during the switch from winter time to summer time (in DST) nothing should change?

[mcargile]

I ran the ADMIN_adjust_GMTnow_on_leads.pl script; however, the lists page in the admin section is still saying that the local time of GMT -6 is:

TIME ZONES WITHIN THIS LIST:
GMT OFFSET NOW (local time) CALLED NOT CALLED
-6.00 (Wed Apr 2007 15:43) 9289 10915

Now when I pull a lead from their database I have this info:

| 1 | 2007-04-11 13:57:00 | 2007-04-11 14:03:11 | NA | VDAD | XXXXXXX | XXXXXXX | 101 | -6.00 | Y | NULL | 217XXXXXXX | NULL | ANDREW | NULL | XXXXXX | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | 1 |

(I Xed out parts of the leads info to protect the clients privacy.)

When I check Verizons page for that areacode it tells me that the local time there is:

Illinois Chicago, Springfield 4/11/2007 4:43:35 PM

Which is one hour ahead of what the list page is showing. Does this mean that the leads need to have the gmt_offset_now adjusted for day light savings time? Reading the comments of the ADMIN_adjust_GMTnow_on_leads.pl script I get the impression that is what the script is supposed to do.

The client did not use the lead loaders with Vicidial, they put them in the DB themselves.

[mflorell]

Doesn't look like your phone_code field is filled in. This has to be a 1 for the ADMIN adjustGMT now script to update those leads properly for the USA.