BTW, note the huge comment in unix/time.c:apr_unix_time_setup() which says that this (* broken) implementation is what was wanted.
-- Jon * AFAIK the P in APR stands for 'portability.' Getting one value under Linux, and another one under HPUX doesn't seem like a Good Thing. On Fri, Jan 04, 2002 at 12:24:11PM -0800, Jon Travis wrote: > I've been experiencing some time funniness on HPUX with respect > to the calculation of the GMT offset. > > Here are the results under HPUX: > > apr_explode_localtime(&xt, 0); > xt.tm_gmtoff = -28800 > xt.tm_isdst = 0 > > apr_explode_localtime(&xt, 967681226000000); > xt.tm_gmtoff = -28800 > xt.tm_isdst = 1 > > > Under my Linux box: > > apr_explode_localtime(&xt, 0); > xt.tm_gmtoff = -28800 > xt.tm_isdst = 0 > > apr_explode_localtime(&xt, 967681226000000); > xt.tm_gmtoff = -25200 > xt.tm_isdst = 1 > > > I believe the problem lies with the fact that we attempt to calculate > 'server_gmt_offset' in the apr_unix_setup_time() function, but the gmt > offset my change when requesting times in a dst different than the > current one. For instance, the current time is used to formulate > server_gmt_offset, and we are not in DST here in US/Pacific. Under > Linux, we get the gmtoffset for free with our localtime call. > I thought it might be that my HPUX box was just wacked out of its > gourd wrt the timezone setup, but it looks correct after investigation. > > Perhaps the correct thing to do is determine the gmt offset during dst > and also when we are not in it, and use different ones in get_offset() > after checking dst (similar to the netware code.) > > -- Jon >
