Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 30 Aug 2001 15:59:54 -0700
From: Brian Pane <bpane@pacbell.net>
Subject: Re: [PATCH] performance fix for time offset computation
To: "Roy T. Fielding" <fielding@ebuilt.com>
Cc: Justin Erenkrantz <jerenkrantz@ebuilt.com>, dev@apr.apache.org
Message-id: <3B8EC56A.1020306@pacbell.net>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801
References: <3B8B71E2.900@pacbell.net>
 <m3r8twxv6i.fsf@rdu88-250-106.nc.rr.com>
 <3B8BDFCD.8050305@pacbell.net> <20010828141251.C1437@waka.ebuilt.net>
 <3B8C184A.4050502@pacbell.net>
 <5.1.0.14.2.20010829093747.00a7b310@mail.charter.net>
 <5.1.0.14.2.20010829101518.00a6ce00@mail.charter.net>
 <20010829151817.B1737@waka.ebuilt.net> <3B8D730C.70200@pacbell.net>
 <20010830135613.H17570@ebuilt.com> <20010830154438.C2142@waka.ebuilt.net>

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