Hi all,
I think that you have some DTS issue with the new time.
I am sending this to PLUM:
POST /webservice/queuecall.php HTTP/1.0
Host: outbound.plumgroup.com
User-Agent: ioncms.com Api
Content-Type: application/x-www-form-urlencoded
Content-Length: 373
login=XXXX
pin=xxxxxxx
phone_number=tel:+xxxx;ani=xxxx
start_url=http://www.mysite.com/call_start.php
result_url=http://www.mysite.com/call_result.php
message_reference=315
call_parameters=try_confirm=0
max_retries=3
retry_interval=600
scheduled_time=19 Mar 2007 11:00:00 -0500
expiration_time=19 Mar 2007 16:00:00 -0500
and in PLUM you save:
Call ID: 524895
Status: uncalled
Campaign Name: default
Phone Number: tel:+xxxx;ani=xxxx
Start URL: http://www.mysite.com/call_start.php
Result URL: http://www.mysite.com/call_result.php
Call Parameters: try_confirm=0
Message Reference: 315
Session ID:
Attempts: 0 of 4
Last Attempt: None
Retry Interval: 10 Minutes
Scheduled Time: Mon, 19 Mar 2007 12:00:00 -0400
Expiration Time: Mon, 19 Mar 2007 17:00:00 -0400
Earliest Time: 0
Latest Time: 0
Callee Type: noattempt
So, I need to work with the right data/time. I am sending the timezone of the local machine. Here in Montreal is -0500. Why you convert this value to -0400? I am doing something wrong?
Thanks.
Omar.
We've Moved! Please visit our new and improved forum over at our new portal: https://portal.plumvoice.com/hc/en-us/community/topics
DTS issue.
-
- Posts: 34
- Joined: Tue Aug 08, 2006 10:00 am
Hello guys, Please when you see this issue, could you explain how PLUM works whit the date, because I am working in a Canada system and we have 3 different timezone, and I think that if I send you the datetime in -0500 I will wait back for a datetime in -0500, the same thing if I send the datetime in -0300 I will wait back for a datetime in -0300. If PLUM does not work like that, please let me know how plum works, Is for plum better GMT (+0000) time zone? I only need to get the same time zone that I have send to PLUM.
Thanks.
Omar.
Thanks.
Omar.
IVR requests based on EST/EDT
Hello,
The scheduled time is relative to EST/EDT based on the standard daylight savings time rules in the US. You should be posting all of your IVR requests with the assumption that the dates are relative to that timezone. If you want absolute times relative to your timezone you should use the attributes start_timestamp and end_timestamp, these variables make use of the unix timestamp capability and are guaranteed regardless of timezone.
Regards,
Plum Support
The scheduled time is relative to EST/EDT based on the standard daylight savings time rules in the US. You should be posting all of your IVR requests with the assumption that the dates are relative to that timezone. If you want absolute times relative to your timezone you should use the attributes start_timestamp and end_timestamp, these variables make use of the unix timestamp capability and are guaranteed regardless of timezone.
Regards,
Plum Support