"ADMIN_adjust_GMTnow_on_leads.pl" reports wrong lo

[ronator]

"ADMIN_adjust_GMTnow_on_leads.pl" reports wrong local_gmt

Hi there,

My leads are logged with GMT+2.

I created a list, and loaded some leads with phone_code 49 for Germany.
I tried to run "ADMIN_adjust_GMTnow_on_leads.pl" -t --debugX --singlelistid=9999 on a test-lead.

First,I get this:
PROCESSING THIS LINE: 49 DEU * +1 Y LSM-LSO Germany
wich is very fine for me.
Then, when SQL comes in play, it says:

|select count(*) from vicidial_list where phone_code='49' and (gmt_offset_now != '2' or gmt_offset_now IS NULL) and list_id='9999 --postal-code-gmt' ;|

|update vicidial_list set gmt_offset_now='2' where phone_code='49' and (gmt_offset_now != '2' or gmt_offset_now IS NULL) and list_id='9999 --postal-code-gmt' ;|

Wondered why !=2 and not !=1 , since this is my gmt (on server and all clients)

So, i opened this script in an editor and went threw to see how the variables are set. It seems to me, local_gmt is correct, cause it is set to 1.00 in the DB, but the var $area_code adds "1" in the DST-calculation.

Actually, I am still confused. At least now I somehow know why my leads are produced with GMT+2; it's GMT+1 plus another "1" for DST.

How can I fix this without changing the php-code ???
How can I run this script and get GMT+1 ???


P.S.:
Since this is kinda newbie-error, maybe creating a sticky thread relating to time-settings/ADMIN_adjust---script could help; i found this thread where it says that the default is GMT+0 (zulu-time) but now way to change this ... --postal-code-gmt won't work outside of the USA, right ?

Greetings

[mflorell]

it's set to +2 because the name of the field is gmt_offset_now, please note the NOW part, since it is meant to change for GMT.

[ronator]

Thank you for your reply.

I am sorry, I can not follow your thougts ...

when i check the field gmt_offset_now in table vicidial_list i got the value 0 and NOT 2. Moreover, it says in the code

Code: Select all

WHERE ... (gmt_offset_now != '$area_GMT')


so I checked for '$area_GMT' which is incremented by

Code: Select all

if ($GBR_DST) {$area_GMT++;}


due to DST.

Since gmt_offset_now is the same value as area_GMT, it will become: 2.

I am thankful for your answer, but it gives me no idea, what I am doing wrong, sorry.

what do i have to do to to get GMT+1 in the list without hacking the script ? the script always looks for [ gmt_offset_now != 2 ] but it should be [ gmt_offset_now != 1 ]

Can anyone follow me ?

I am sorry, If feel very stupid, please help me, i don't get the idea of the last statement/reply ... I noted the "NOW" in your statement, so what ???

Best wishes ...

P.S.: maybe it helps setting gmt_offset_now to 1.00 per default (since 0.00 is actually the default). Is that okay, to do so ????

I'd like to get some feedback before I try it !!!
I wonder why this is not configureable in the web-interface (since local server time IS gmt+1).

[mflorell]

I do not understand why you need the current offset from ZULU time for German records to be +1 when they should be +2 right now

http://www.timeanddate.com/worldclock/city.html?n=37

Please explain.

[ronator]

Sorry when I confused you. Maybe all the stuff I mentioned is not related to the real problem. We'll see, I hope ...

Let me begin slowly:
server time is gmt+1, client time is also gmt+1.
We have Summertime, so DST is active. "hwclock --show" gives me the correct local time. I checked the Inbound/Closer Report and I have to face the fact, that all my calls in the TIME STATS section are displayed one hour before. We start at 8.00 but the stats show the calls were made at 7.00.

Actually, I dont what interferres with the logs.
But, in fact, the closer statistics are one hour to early.

Stupidly, I never documented the setup on my old machine (vici 1.1), but I compared them both to each other. Both have (in mysql) gmt_offset_now="0.00". When I compare the LISTS, I can see on my old system this:

TIME ZONES WITHIN THIS LIST:GMT OFFSET NOW (local time)CALLED NOT CALLED
+1.00 (Tue Apr 2010 08:58) 384804 0

yes, my agents made about 384 K calls and they are logged at gmt+1

Whereas on the new system it's like this:
+2.00 (Tue Apr 2010 10:03) 3357 9

Here, in fact, the time IS correct.

Well, maybe I never really understood anything I did, but after loading leads again and again (also trying 42 for (I think) mexiko to see any change), I thought I recognized that this GMT+2 is caused by GMT + 1 local hour + 1 hour for DST. That'd make sense at least.

But the real problem is: the closer stats starting at seven ... and I don't know how to fix this ...

Thank you very much for your patience with me :)

[mflorell]

admin.php version and build?

[ronator]

VERSION: 2.0.5-174
BUILD: 90522-0506

[mflorell]

This might actually be fixed in 2.2.0rc8, I believe there was a bug in the report.

[ronator]

Ok, if that's the case, i should give it a try. I appreciate your help, but generally speaking, I consider "believing" is not the best argument for an upgrade. Are there any known issues or problems in upgrading to 2.2 ?

Moreover I would like to know if there are any concerns relating to updating the system per webmin. By the way, adding webmin to vicidial was a good job; I used to do it on my own "back in those days" ...

Will there be a new vicidial-manual with the astgui-update and if we allready paid for the old manual, do we have to pay again for the new one ?

It seems to me, sun is always shining in Florida :) I hope mflorell gets enough sleep though ^^

Best wishes
Ron Salvatore

[mflorell]

The only issues we have seen with upgrades to 2.2.0rc8 is people not following all of the UPGRADE steps.

Yes there is a new manual for 2.2.0(it was released in January) and if you had purchased a manual within the last 12 months you would have received a link to download the update for free. If it has been longer than 12 months since you purchased the manual you would need to buy a new download account.

It is nice and sunny here in Florida, but I rarely get enough sleep

[ronator]

just to inform everybody:

I took a parallel system, installed vici 1.3 from iso/cd, configured network settings, convinced webmin to let me login (# /usr/libexec/webmin/changepass.pl /etc/webmin root password), installed all system-updates Through webmin-interface (80 packages), rebooted, just followed the update-to-vicidial-2.2-HOWTO, check in to SVN etc. ...

and, surprise, it works ! Found all the stuff and options I missed and more than that! But I did not already have the time to test it all (especially the "1-hour-lasting-REPORT-bug", if I may called it like that).

But, alltogether I am kinda like overwhelmed by all the new options (Voicemail, Campaign-Settings,In-Groups-Settings).

Very good job, folks !!!!!!!

- this thread might be closed -

Best wishes,
Ron Salvatore

P.S.: Special thanks to mflorell for being so kind and patient ... there are some forum-admins out there, who should take a leaf out of his book!

[mflorell]

Thanks for reporting your experiences, I'm glad you like all the new features and we are happy to help.

[ronator]

but maybe you should tell somewhere, that some configuration-settings change, e.g. agent alert extension, which was 8304 and seems to be 83047777777777 what let me had a morning full of action ;)

nevertheless, nice job!

[mflorell]

I will add this as a step in the UPGRADE doc process for the future:

3. For each of your ViciDial servers, go the Admin -> Servers -> Modify Server page and set each one to "Rebuild conf files = Y" and click submit. This will rebuild the conf files to ensure any changes are updated.