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
