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 > >US/Eastern). > >> > > >> >Then the calculation must be wrong, since EDT is -0400. EST is > >-0500. > >> > >> How is the calculation wrong? It should be 5, it is 5, I don't > >see > >> 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 don't particularly care how it works -- I just want to see its behavior documented if the value is cached during EDT but used during EST; i.e., what happens when the cached value is stale. Alternatively, if you are storing only the standard offset and a value for the daylight time separately, then how do we know when the daylight time has changed? ....Roy
