Re: [Users] Mbuni m-retrieve-conf dates
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
Re: [Users] Mbuni m-retrieve-conf dates
For now we've made it go away by setting the timezone on the machine we're using as an MMSC to UTC, so I probably won't have time to look at it any time soon. If I ever do wind up finding anything, I will post it to one of the lists. Meggie Ladlow Software Engineer II TECORE Networks Phone: +1 410 872 6323 Fax: +1 410 872 6010 email: mlad...@tecore.com - Original Message - 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 - Original Message - 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 - Original Message - 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:
Re: [Users] Mbuni m-retrieve-conf dates
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 - Original Message - 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
Re: [Users] Mbuni m-retrieve-conf dates
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 ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users
Re: [Users] Mbuni m-retrieve-conf dates
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 - Original Message - 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 - Original Message - 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
