RE: SMPP Time definitions - deferred/validity

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