RE: FW: Validity Period wrong calculation in SMPP code

I agree with James on this - using relative times is much easier to deal
with - clocks don't matter. I've got a patch for this around here
somewhere if anyone's keen. 

But for backwards compatibility (support 3.3) the gwqdiff calculation
could just be improved to consider years (+ leap), months and days to
those trailing GMT. This is location of the bug no? 

ie:

gwqdiff = ((localtime.tm_hour - gmtime.tm_hour) * 4)
         + ((localtime.tm_min - gmtime.tm_min) / 15);

gwqdiff = (((localtime.tm_day - gmtime.tm_day) * 24 +
            (localtime.tm_hour - gmtime.tm_hour)) * 4)
         + ((localtime.tm_min - gmtime.tm_min) / 15);

would give the correct offset. Note: this is not a patch obviously needs
improving - will provide more thorough patch shortly. 

Cheers,
Alan


On Thu, 2004-11-18 at 03:25, James Noctor wrote:
> From an SMPP protocol point of view, I find it is straight forward to
> get the current GMT (aka UTC) on pretty much any platform, so it's
> easy to set the validity time interms of the current GMT time + offset
> (seconds/minutes...), and let the SMSC do the convertion to its local
> time. Easier still is to use the relative time format, but only if the
> SMSC is 3.4 and not 3.3 (which is why we use the former method -
> backward compatible).
> 
> 
>  
> Hi Paul - long time no hear!
> 
> Jim Noctor
> NCL Technologies
> Provato SMS MMS Gateway
> 
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Paul Keogh
> Sent: 17 November 2004 13:51
> To: [email protected]
> Subject: RE: FW: Validity Period wrong calculation in SMPP code
> 
> 
> 
> >
> > Btw. I don't know, why we calculate local <-> utc diff and
> > for what it should be good? Patch just set timestamps in utc...
> >
> 
> Hmm, but does'nt the 3.4 spec say that the time stamp includes local
> time value in quarter hours offset +/- from UTC. (section 7.1.1)
> 
> Your patch just sets the quarter hour offset to 0, so you effectively
> ignore any local time offset ? Won't this confuse the SMSC ?
> 
> But, this time stuff makes me confused :-)
>