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]
> 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 :-)
>
