RE: [PATCH] SMPP validity
"Oded Arbel" <[email protected]>
| Newsgroups | gmane.comp.mobile.kannel.devel |
|---|---|
| Message-ID | <[email protected]> |
> -----Original Message----- > From: Vibhu Mohindra [mailto:[email protected]] > > This is with respect to the CVS version of Kannel. The SMPP driver's > calculation of the validity and deferred fields for messages > to the SMSC > is incorrect. (I noticed this because it worked with my simulator at > 2340 hrs but not at 0100 hrs. Sure enough in the first case > it correctly > said I was +6 UTC, but in the second it said I was -18 UTC. Of course > the simulator then returned a NAK). > localtime() originated from SysV. Upon return it sets a global called > timezone, which stores the offset from UTC. This isn't nice for > multithreaded programs. (Though in this particular case it's probably > alright since one's UTC offset won't change from one call to > the next). A > POSIX.1c variant is localtime_r(). This gives you the offset > required in > a local variable (in addition to setting the global timezone). While a > solution with localtime() would be fine, the only drawback is > it doesn't > take into account daylight savings which localtime_r() does. I don't understand what your patch is doing. my manual pages clearly claim : <snip> The localtime() function converts the calendar time timep to broken-time representation ... The localtime_r () function does the same, but stores the data in a user-supplied struct. It need not set tzname. </snip> So using localtime_r() over localtime() has no advantage to us (especially as we use a serializing wrapper over the system's localtime() ), except making the code less portable as localtime_r() is not available on all platforms. the struture member you are using, tm_gmtoff, is returned by localtime() too, as both are returning the same structure, and is only available on glibc (libc6 and above) making the code even less protable! I agree that the current offset calculation is not correct for certain edge conditions, but we need to fix it by fixing the algorithm, not by introducing portability issues. I vote -1 on that patch. -- Oded Arbel m-Wise mobile solutions [email protected] +972-9-9581711 (116) +972-67-340014 ::.. If you lie to the compiler, it will get its revenge. -- Henry Spencer > > My changes are attached. I updated my copy of the CVS tree at > approximately 17:30 GMT on 21 Aug and this is a diff to it. > > Vibhu >