> > In that case the calculation to get the difference in minutes may be > > more like > > > > (local_tm.tm_year - gmt_tm.tm_year) * 365*24*60 + > > (local_tm.tm_yday - gmt_tm.tm_yday) * 24*60 + > > (local_tm.tm_hour - gmt_tm.tm_hour) * 60 + > > (local_tm.tm_min - gmt_tm.tm_min ); > > Why would I want to handle years and days when I only need the hour > difference ?
OK, here's why looking only at hours and minutes isn't enough. A country which is +12 GMT will be identified at 11am as being -12 GMT. Past noon it will be correctly identified as +12 GMT. Our normalising version which adds/subtracts 24 hours doesn't work for such a place. The problem is similar for a place which is -12 GMT. I believe that it is not a matter of correcting the normalising algorithm proposed. In fact, this cannot be corrected only by looking at hours and minutes. So you get into the process of comparing days of the year as well. That leads to having to compare years as well to account for wrap arounds on New Year's. That leads to accounting for leap years... Working with dates is not easy, and one shouldn't assume an "easy" algorithm will work, and so why go to the bother of using a library function. I am not lazy at all and will gladly dive into re-implementing this algorithm for Kannel if it is so desired, and we are prepared to go through the same amount of testing etc. that the library implementors have already gone through, to produce something as correct and reliable. Vibhu
msg04721/pgp00000.pgp
Description: PGP signature
