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 Wed, 29 Aug 2001 22:56:12 GMT
Roy T. Fielding wrote:

>On Wed, Aug 29, 2001 at 10:19:40AM -0400, Greg Marr wrote:
>>At 10:05 AM 08/29/2001, William A Rowe wrote:
>>>>At 07:36 PM 08/28/2001, Roy T. Fielding wrote:
>>>>>On Tue, Aug 28, 2001 at 03:16:42PM -0700, Brian Pane wrote:
>>>>>>As far as I can tell, the result of the calculation should be
>>>>>>independent of daylight savings (e.g., always 5 for 
>>>>>Then the calculation must be wrong, since EDT is -0400.  EST is 
>>>>How is the calculation wrong?  It should be 5, it is 5, I don't 
>>>>the problem.
>>>Only if you collect DT as +0100 in a seperate operation, and use the 
>>>net result (-0400) when computing between LT and ST.
>>I wasn't referring to the usage of the value, I was referring to the 
>>calculation itself.  Brian said it was independent of DST, and 
>>produced 5 for US/Eastern.  Roy said the calculation must be wrong 
>>since EDT is -0400, which makes no sense.
>Well, at this point, I don't understand what the heck you guys are talking
>about.  The patch introduced a cache for the gmtoffset which, just as it
>is named, represents the time difference from GMT/UTC to local time.  Right?

>For a system located in Maryland, USA, the gmtoffset is negative four hours
>during daylight time and negative five hours during standard time, so if
>you store a cached value of the offset then the value is going to be
>four or five.  If the calculation always results in five, then obviously
>something is wrong.  Either the calculation is wrong or what it is
>calculating is not the gmtoffset.
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.


View raw message