apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject Re: [PATCH] performance fix for time offset computation
Date Thu, 30 Aug 2001 22:59:54 GMT
Roy T. Fielding wrote:

>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.
>
Sounds reasonable to me.  I'll repost the patch in a minute with
some added comments documenting why it computes and caches a DST-unaware
offset.

--Brian




Mime
View raw message