Page 1 of 1

Time zone suddenly not right

PostPosted: Thu Sep 18, 2008 9:03 am
by nkasoff
Suddenly last night, Vicidial started making calls at 3 am. We have a campaign set for 8 am to 9 pm. Yesterday it stopped calling at 6 pm, and resume this morning at 3 am. Vicidial admin shows correct time. Time zone in /etc/sysconfig/clock is correct, and is also correct in the Vicidial server config. What else do I need to look at?

PostPosted: Thu Sep 18, 2008 9:40 am
by mflorell
What do the gmt_offset_now entries in the vicidial_list table look like?

would you happen to have debug output from when the AST_VDhopper.pl script ran at 3AM?

PostPosted: Thu Sep 18, 2008 12:22 pm
by nkasoff
> What do the gmt_offset_now entries in the vicidial_list table look like?

The offending list is #169, and gmt_offset_now was 0 for everything in that list. We are in central time, GMT-6.

I still have my log files, just not sure which one you want. Let me know, I can post it or email it as you prefer.

mysql> select gmt_offset_now,count(*) from vicidial_list group by gmt_offset_now;
+----------------+----------+
| gmt_offset_now | count(*) |
+----------------+----------+
| -7.00 | 49656 |
| -6.00 | 11131 |
| -5.00 | 148088 |
| -4.00 | 17651 |
| 0.00 | 7302 |
| 10.00 | 15 |
+----------------+----------+

mysql> select gmt_offset_now,count(*) from vicidial_list where list_id=169 group by gmt_offset_now;
+----------------+----------+
| gmt_offset_now | count(*) |
+----------------+----------+
| 0.00 | 7300 |
+----------------+----------+
1 row in set (0.11 sec)

mysql> select count(*) from vicidial_list where list_id=169;
+----------+
| count(*) |
+----------+
| 7300 |
+----------+
1 row in set (0.01 sec)

PostPosted: Thu Sep 18, 2008 12:25 pm
by nkasoff
I just checked, vicidial_phone_codes is fine.

PostPosted: Thu Sep 18, 2008 1:32 pm
by mflorell
Inside that list what are the phone_code fields populated with?

PostPosted: Thu Sep 18, 2008 1:49 pm
by nkasoff
Here's a sampling. We have run another campaign since then, and it worked fine. So it doesn't seem to be a data problem. And it has never happened before, in about 100 campaigns.

The problem is, it exposes us to HUGE legal liability if a campaign starts running at 4 in the morning. I have written a quick php routine to allow them to check a list after they import it to be sure this doesn't happen again. But since our calls are always in the United States, we should never have anything in other time zones, and if we do, it means something is wrong. How hard would it be to add an "allowable time zones" range in server setup?
-------------------------------
mysql> select * from vicidial_phone_codes where country_code=1 limit 15;
+--------------+---------+----------+-------+------------+------+-----------+------------------------+
| country_code | country | areacode | state | GMT_offset | DST | DST_range | geographic_description |
+--------------+---------+----------+-------+------------+------+-----------+------------------------+
| 1 | USA | 201 | NJ | -5 | Y | SSM-FSN | |
| 1 | USA | 202 | DC | -5 | Y | SSM-FSN | |
| 1 | USA | 203 | CT | -5 | Y | SSM-FSN | |
| 1 | CAN | 204 | MB | -6 | Y | SSM-FSN | |
| 1 | USA | 205 | AL | -6 | Y | SSM-FSN | |
| 1 | USA | 206 | WA | -8 | Y | SSM-FSN | |
| 1 | USA | 207 | ME | -5 | Y | SSM-FSN | |
| 1 | USA | 208 | ID | -7 | Y | SSM-FSN | |
| 1 | USA | 209 | CA | -8 | Y | SSM-FSN | |
| 1 | USA | 210 | TX | -6 | Y | SSM-FSN | |
| 1 | USA | 212 | NY | -5 | Y | SSM-FSN | |
| 1 | USA | 213 | CA | -8 | Y | SSM-FSN | |
| 1 | USA | 214 | TX | -6 | Y | SSM-FSN | |
| 1 | USA | 215 | PA | -5 | Y | SSM-FSN | |
| 1 | USA | 216 | OH | -5 | Y | SSM-FSN | |
+--------------+---------+----------+-------+------------+------+-----------+------------------------+
15 rows in set (0.00 sec)

PostPosted: Thu Sep 18, 2008 1:59 pm
by mflorell
I'm not looking for the vicidial_phone_codes table, I'm looking for the values in the phone_code field of the vicidial_list table for those entries that are showing a 0 for the gmt_offset_now.

PostPosted: Thu Sep 18, 2008 2:09 pm
by nkasoff
In every case, the value was 100.

PostPosted: Thu Sep 18, 2008 2:52 pm
by mflorell
If you are calling the USA it should be '1'

if it is set to 100 it will not find any of the timezone records, because that is not a valid country dialing code. Change all of those to 1 and rerun the adjust_gmt perl script.

PostPosted: Thu Sep 18, 2008 5:20 pm
by nkasoff
How would it be set to 100 in the first place? Is this where the "phone code override" on the list import ends up? If so, this could be a case of operator error. But it actually did make the calls, because we got angry return calls from people who we woke up.

PostPosted: Thu Sep 18, 2008 5:30 pm
by mflorell
Yes that is the phone code override field.

As for how the calls were placed, you would have to look at the asterisk logs. It is possible that you have phone code dial prefix disabled in the campaign detail screen.