apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@ebuilt.com>
Subject Re: [PATCH] performance fix for time offset computation
Date Thu, 30 Aug 2001 22:44:38 GMT
On Thu, Aug 30, 2001 at 01:56:13PM -0700, 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?

I am still +1 on the patch -- I just want someone who understands what
the heck it is doing to add documentation, like they are SUPPOSED to do,
so that I don't have to ask annoying questions about its behavior.
[Or at least so that its easy to tell me to go RTFM.]  Right now it
is relying on a side-effect of the proceesing of an OS-dependent data
structure to obtain some performance benefit, which is a fine idea if
it is properly documented as such.

....Roy


Mime
View raw message