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
