Indeed we do use Kannel's libs for these conversions. It is possible that there 
is a switch in timezones. Let us know if you can track it down.

Paul.

On May 04, 2012, at 16:18, Margaret Ladlow wrote:

> When the sender inserts a date, the date is altered. I have the date in a 
> m-send-req as 4F746F93 and in the corresponding retrieve as 4F74A7D3 
> (basically goes from 14:20 GMT - correct to 18:20 GMT - incorrect).
> 
> I didn't really communicate this well in the original post, but it's very 
> weird to me that most phones continue to display the correct timestamp. This 
> only causes difficulty on *one* of my test phones. I was going to try and 
> find the place in the code where it applies this offset and play around with 
> it there but I'm having trouble doing finding it since all the time 
> conversion code (from HTML to long and vice versa) seems to convert without 
> the application of any offset whatsoever.
> 
> Meggie Ladlow
> Software Engineer II
> TECORE Networks
> Phone:      +1 410 872 6323
> Fax:          +1 410 872 6010   
> email:   mlad...@tecore.com
> 
> You need to look at the original m-send-req transaction as well. Does the 
> sender insert a date? If not, the server will insert its own local time.
> 
> 
> On May 04, 2012, at 15:38, Margaret Ladlow wrote:
> 
> Paul,
> 
> Thanks. I'm aware that no timezone information is explicitly included. My 
> understanding from the spec was that GMT is assumed in the long integer. So 
> if mbuni is sending that second value (1336063655), the phone should think it 
> is receiving 16:47 GMT, but this would be incorrect. Then, if the phone 
> applied the local offset (GMT-4), it would display 12:47, which would be the 
> incorrect date and time for the message (8:47), but it wouldn't have any way 
> of knowing otherwise.
> 
> So I'm still not sure why mbuni is sending 4FA2B6A7 instead of 1336049255.
> 
> Meggie Ladlow
> Software Engineer II
> TECORE Networks
> Phone:      +1 410 872 6323
> Fax:          +1 410 872 6010   
> email:   mlad...@tecore.com
> 
> Users list is the right place to ask, but the answer is this: The date is 
> sent to the phone as a long integer. No timezone information is included. 
> Therefore the phone must work out the correct time zone. I believe this is 
> where the problem lies.
> 
> Paul.
> 
> On May 03, 2012, at 21:34, Margaret Ladlow wrote:
> 
> Hi,
> 
> I'm not sure if the users list or the devel list would be more appropriate 
> than this one for this question, so please let me know if I should subscribe 
> to one of them and post there instead.
> 
> I have noticed in wireshark that when my phones get m-retrieve-conf from the 
> MMSC that the date seems to be wrong. My understanding from the spec is that 
> the date should be encoded in the message as seconds since the epoch in GMT. 
> One scenario I have is a message sent at 8:47:35 (local time). This comes out 
> to 1336049255 seconds since the epoch (GMT 12:47:35). However in the 
> m-retrieve-conf message the date is 1336063655 (4FA2B6A7), which is 12:47:35 
> in localtime and 16:47:35 with gmtime_r. 
> 
> All of the phones except one I'm using for testing display the correct 
> (local) timestamp regardless. The one that doesn't work displays the 
> timestamp in GMT instead of local time. I am not sure if the phones are just 
> displaying the time they received the message and the phone that doesn't work 
> is the only one using the timestamp from the message or if the rest of the 
> phones expect the weird time and are compensating for it.
> 
> Is there any way someone who's worked on Mbuni could point me in the 
> direction where this date switching happens or let me know why it is 
> happening?
> 
> Thank you,
> 
> Meggie Ladlow
> Software Engineer II
> TECORE Networks
> Phone:      +1 410 872 6323
> Fax:          +1 410 872 6010   
> email:   mlad...@tecore.com
> 
> 
>  
> This e-mail may contain privileged, confidential, copyrighted or other 
> legally protected information, and is intended exclusively for the intended 
> recipient. If you are not the intended recipient (even if the e-mail address 
> above is yours), you may not review, store, use, copy, disclose or retransmit 
> it in any form. If you are not the intended recipient or otherwise have 
> received this by mistake, please immediately notify the sender by return 
> e-mail (or sysad...@tecore.com), then delete the message in its entirety. 
> Thank you. 
> 
> 
> 
>  
> This e-mail may contain privileged, confidential, copyrighted or other 
> legally protected information, and is intended exclusively for the intended 
> recipient. If you are not the intended recipient (even if the e-mail address 
> above is yours), you may not review, store, use, copy, disclose or retransmit 
> it in any form. If you are not the intended recipient or otherwise have 
> received this by mistake, please immediately notify the sender by return 
> e-mail (or sysad...@tecore.com), then delete the message in its entirety. 
> Thank you. 
> _______________________________________________
> Users mailing list
> Users@mbuni.org
> http://lists.mbuni.org/mailman/listinfo/users
> 
> 
> 
>  
> This e-mail may contain privileged, confidential, copyrighted or other 
> legally protected information, and is intended exclusively for the intended 
> recipient. If you are not the intended recipient (even if the e-mail address 
> above is yours), you may not review, store, use, copy, disclose or retransmit 
> it in any form. If you are not the intended recipient or otherwise have 
> received this by mistake, please immediately notify the sender by return 
> e-mail (or sysad...@tecore.com), then delete the message in its entirety. 
> Thank you. 

_______________________________________________
Users mailing list
Users@mbuni.org
http://lists.mbuni.org/mailman/listinfo/users

Reply via email to