If the issue is solely with locatime_r(), but using localtime() and the returned struct's tm_gmtoff is alright then let's do that rather than re-implementing a (non-trivial?) algorithm. The struct returned by localtime() is in a global area, but if that's alright then let's go for it.
> gmtime = gw_gmtime(time(NULL));
> localtime = gw_localtime(time(NULL));
> gwqdiff = ((localtime.tm_hour - gmtime.tm_hour) * 4)
> + ((localtime.tm_min - gmtime.tm_min) / 15);
> +gwqdiff = gwqdiff>12?gwqdiff-24:gwqdiff;
I'm actually +6 UTC. However early in the morning it detected me as
-18 UTC. Not +18, so the algorithm given won't work in this case, or
for other cases east of Greenwich. Also it doesn't take into account
daylight savings (I admit I don't know much about daylight savings, not
living in a country where they apply). You get all this for free with
tm_gmtoff. Of course if the tm_gmtoff member of the struct itself is only
present on some platforms and is non-portable then we should definitely
re-implement the algorithm. Could you let me know if this is so.
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 );
but this has a problem with leap years. Maybe it's simpler with your
approach. Something to normalise the time like
gmtime = gw_gmtime(time(NULL));
localtime = gw_localtime(time(NULL));
gwqdiff = ((localtime.tm_hour - gmtime.tm_hour) * 4)
+ ((localtime.tm_min - gmtime.tm_min) / 15);
+gwqdiff = gwqdiff>12?gwqdiff-24:gwqdiff;
+gwqdiff = gwqdiff<12?gwqdiff+24:gwqdiff;
Is this error free?
Vibhu
msg04712/pgp00000.pgp
Description: PGP signature
