Right you are - haven't thought about that one :-) +1 from me, as it is now (i.e : haven't thought of a cute format hack to address the +gwqdiff negative issue).
-- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 +972-67-340014 ::.. Indecision is the true basis for flexibility. -----Original Message----- From: Alan McNatty [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 26, 2002 12:01 AM To: Oded Arbel Cc: Kannel Dev Subject: RE: SMPP Time definitions - deferred/validity Hi Oded, Have implimented as you suggest but I left out an extra step that is needed to make gwqdiff absolute before adding to buffer. Note: bonus points for anyone that can come up with a fancy format string method of doing it - I've just forced in negative case (see patch). Cheers, Alan On Tue, 2002-06-25 at 20:34, Oded Arbel wrote: > I've submitted patches to that effect twice already, but one that was applied was >later revered. I suggest to change the code, instead of by removing the redundant 0 >in the format string, by removing the redundant %01d which matches the hardcoded 0 in >the argument list - for obvious gains : > > current implementation - > buffer = octstr_format("%02d%02d%02d%02d%02d%02d0%01d%02d%1s", > tm.tm_year % 100, tm.tm_mon + 1, tm.tm_mday, > tm.tm_hour, tm.tm_min, tm.tm_sec, > 0, gwqdiff, octstr_get_cstr(relation_UTC_time)); > > Fix suggested by Alan - > buffer = octstr_format("%02d%02d%02d%02d%02d%02d%01d%02d%1s", > tm.tm_year % 100, tm.tm_mon + 1, tm.tm_mday, > tm.tm_hour, tm.tm_min, tm.tm_sec, > 0, gwqdiff, octstr_get_cstr(relation_UTC_time)); > > My suggestion - > buffer = octstr_format("%02d%02d%02d%02d%02d%02d0%02d%1s", > tm.tm_year % 100, tm.tm_mon + 1, tm.tm_mday, > tm.tm_hour, tm.tm_min, tm.tm_sec, > gwqdiff, octstr_get_cstr(relation_UTC_time)); > > -- > Oded Arbel > m-Wise mobile solutions > [EMAIL PROTECTED] > > +972-9-9581711 > +972-67-340014 > > ::.. > Keep me away from the wisdom which does not cry, > the philosophy which does not laugh and the greatness > which does not bow before children. > -- Kahlil Gibran > > -----Original Message----- > From: Alan McNatty [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, June 25, 2002 8:46 AM > To: Kannel Dev > Subject: SMPP Time definitions - deferred/validity > > > Hello All, > > I've been looking at the SMPP 3.4 schedule_delivery_time and > validity_period implimentation in kannel by dumping the submit_sm pdu's > and comparing against tcpdump's and specs. Emabling full (pdu) debugging > gives ... > > ... > ...52:22 [5] DEBUG: schedule_delivery_time: "0206251653220048" > ...52:22 [5] DEBUG: validity_period: "0206251653220048" > > Where as the SMPP 3.4 spec by definition require times to be in the > format ...YYMMDDhhmmsstnnp. Extra debugging provides my gwqdiff as 48 so > as you can see from this that the tnnp part looks out of line > > The culprit is an extra '0' in the buffer creation (see patch). The > result ... > > ... > ...37:25 [5] DEBUG: schedule_delivery_time: "020625184725048+" > ...37:25 [5] DEBUG: validity_period: "020625183825048+" > > > I'm still testing smsc's capability (at time of writing smsc is ignoring > deferred timing - although this may be a server clock issue) however the > enclosed patch is required regardless I believe. > > Cheers, > Alan
