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 >>>>>> >>>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? > 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. --Brian