Justin Erenkrantz wrote:
On Wed, Aug 29, 2001 at 03:56:12PM -0700, Brian Pane wrote:
I disagree. Consider how the result of the calculation is used. We get the offset from the current time and then plug it into the time struct for a *completely different* time (in the explode_time function). So the offset for computed by get_offset() for a machine in US/Eastern should always be -5 (really -5*3600). If DST happens to be in effect, using -4 would be an error; there's no guarantee that the time to which we'll be applying the offset is on a date when DST is in effect. The only safe thing to do is use the nominal offset for the location (-5 in this example) and then adjust it in the final apr_exploded_time_t if *that* time (not the current time) is on a date when DST applies.
Can we come to a conclusion on this?
In my tests, I see gmtime_r being a huge bottleneck.
At the very worst, have the timezone cached for 1 hour (or even better
build in to it knowledge when the timezone *may* change). The cache check would be a lot cheaper than the call to gmtime_r (which on Solaris at least is a serialization point...). -- justin
+1 on the patch. (sick of seeing 9 time calls for every mod-include request)
