Re: Is the time from Kannel using the timezone?

Andreas Fink <[email protected]>
Newsgroups gmane.comp.mobile.kannel.devel
Message-ID <[email protected]>
On 04.06.2007, at 10:46, Hillel Bilman wrote:

> Hi,
>
> Any ideas how to ensure Kannel reports back the time corrected for  
> your time
> zone.
> We are using %t to get back the timeDate.  The submit_sm_resp is at  
> 09:15:06
> but Kannel gives back the timeDate=2007-06-04+07:15:06.
>
> South African time (SAST) is 2 hours ahead of UTC (UTC +2) so how do I
> configure Kannel to give back the timeDate corrected for South  
> African time
> zone?
>
> Is there another option other than %t to ensure you get back the  
> time and
> date corrected for your time zone, when the SMSC responds with the
> submit_sm_resp?
>
> Is this a Linux configuration issue or Kannel bug?  (We have left the
> default of --enable-localtime when configuring Kannel.)
>


there are two different times being used

a) the one from the machine
b) the one in the SMS PDU.


for a) simply set your timezone of the machine correctly and set TZ  
variable accordingly.
Also compile kannel to print out everything in local timezone and not  
in UTC (./configure --enable-localtime)

for b) this is given from the operator's SMSC. Nothing you can do  
about it. If the operator reports wrong time, then thats what he does...


> Any ideas appreciated
>
>> From bearerbox log (should be time date submit_sm_resp was received
> 2007-06-04 09:15:06):
> 2007-06-04 09:15:06 [13977] [13] DEBUG: SMPP[smsc1]: Got PDU:
> 2007-06-04 09:15:06 [13977] [13] DEBUG: SMPP PDU 0x94bb040 dump:
> 2007-06-04 09:15:06 [13977] [13] DEBUG:   type_name: submit_sm_resp
> 2007-06-04 09:15:06 [13977] [13] DEBUG:   command_id: 2147483652 =
> 0x80000004
> 2007-06-04 09:15:06 [13977] [13] DEBUG:   command_status: 0 =  
> 0x00000000
> 2007-06-04 09:15:06 [13977] [13] DEBUG:   sequence_number: 4004 =  
> 0x00000fa4
> 2007-06-04 09:15:06 [13977] [13] DEBUG:   message_id: "d9297e"
> 2007-06-04 09:15:06 [13977] [13] DEBUG: SMPP PDU dump ends.
> 2007-06-04 09:15:06 [13977] [13] DEBUG: DLR[mysql]: Adding DLR  
> smsc=smsc1,
> ts=14231934, src=2783930012345678, dst=27832121234, mask=31,  
> boxc=dlrbox
> 2007-06-04 09:15:06 [13977] [13] DEBUG: sql: INSERT INTO dlr (smsc,  
> ts,
> source, destination, service, url, mask, boxc, status) VALUES  
> ('truteq',
> '14231934', '2783930012370201', '27832124956', 'tester',
> 'http://batchDeliveryReceipt?smsId=465308&status=%d&smsc=% 
> i&timeDate=%t&dest
> ination=%p&delivInfo=%a&source=%P&msgid=%k', '31', 'dlrbox', '0');
>
>> From smsbox log (timeDate is 2 hours behind = 2007-06-04+07:15:06):
> 2007-06-04 09:15:06 [14007] [3] INFO: sendsms sender:<xxx:  
> 2783930012345678>
> (127.0.0.1) to:<27832121234> msg:<message>
> 2007-06-04 09:15:06 [14007] [9] DEBUG:   Query:
> smsId=465308&status=8&smsc=smsc1&timeDate=2007-06-04 
> +07:15:06&destination=27
> 832121234&delivInfo=ACK%2F&source=2783930012345678&msgid=ACK%2F

I don't see the problem here. Which timestamp is now not correct? The  
one reported back from the SMSC?

>
> I've set the clock to UTC and it's the correct time zone.
>
> cat /etc/sysconfig/clock
> ZONE="Africa/Johannesburg"
> UTC=true
> ARC=false
>
> ln -s  /usr/share/zoneinfo/Africa/Johannesburg   /etc/localtime
>
> Set the hardware clock by executing:   /sbin/hwclock -systohc
>
> date -u
> Mon Jun 4 08:30:08 UTC 2007
>
> date
> Mon Jun 4 10:30:08 SAST 2007
>
> We are using Linux Redhat Enterprise.



Andreas Fink

Fink Consulting GmbH
Global Networks Schweiz AG
BebbiCell AG

---------------------------------------------------------------
Tel: +41-61-6666330 Fax: +41-61-6666331  Mobile: +41-79-2457333
Address: Clarastrasse 3, 4058 Basel, Switzerland
E-Mail:  [email protected]
www.finkconsulting.com www.global-networks.ch www.bebbicell.ch
---------------------------------------------------------------
ICQ: 8239353 MSN: [email protected] AIM: smsrelay Skype: andreasfink
Yahoo: finkconsulting SMS: +41792457333
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.