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
