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. ....Roy
