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
