Ok, here's a small patch which gets things working correctly for me.
Not sure if this patch is correct, though.
-- Jon
Index: time.c
===================================================================
RCS file: /home/cvspublic/apr/time/unix/time.c,v
retrieving revision 1.58
diff -u -r1.58 time.c
--- time.c 2 Jan 2002 20:12:34 -0000 1.58
+++ time.c 7 Jan 2002 21:13:09 -0000
@@ -93,6 +94,8 @@
return server_gmt_offset + daylightOffset;
}
#endif
+ if(tm->tm_isdst)
+ return server_gmt_offset + 3600;
return server_gmt_offset;
#endif
}
@@ -341,7 +344,6 @@
struct timeval now;
time_t t1, t2;
struct tm t;
- int was_dst;
gettimeofday(&now, NULL);
t1 = now.tv_sec;
@@ -352,10 +354,9 @@
#else
t = *gmtime(&t1);
#endif
- was_dst = (t.tm_isdst > 0);
t.tm_isdst = -1;
t2 = mktime(&t);
- server_gmt_offset = (apr_int32_t) difftime(t1, t2) + (was_dst ? 3600 : 0);
+ server_gmt_offset = (apr_int32_t) difftime(t1, t2);
#endif
}
On Fri, Jan 04, 2002 at 02:59:42PM -0800, Brian Pane wrote:
> Jon Travis wrote:
>
> >On Fri, Jan 04, 2002 at 02:39:56PM -0800, Brian Pane wrote:
> >
> >>Jon Travis wrote:
> >>
> >>>BTW, note the huge comment in unix/time.c:apr_unix_time_setup()
> >>>which says that this (* broken) implementation is what was wanted.
> >>>
> >>Yes, in the sense that it produces the same results that we had back
> >>when we were doing the GMT offset within get_offset(). I just ran
> >>your test case on Solaris 2.8, and it produces the same results as
> >>HP-UX--both with the latest unix/time.c and with the last version
> >>(rev 1.51) from before the GMT offset computation was moved into
> >>apr_unix_time_setup().
> >>
> >
> >So, you're just saying that it is just as broken as it was before the
> >change in 1.52?
> >
>
> Right. Basically, that field has different semantics on HP-UX and Solaris
> than it has on Linux. That doesn't seem to be a problem for any of the
> time manipulation code, although the fact that the field is part of the
> publicly visible apr_time API is bad for portability. I'm in favor of
> making the semantics consistent across all platforms (e.g., using the
> Netware approach as you described) if it can be done without breaking
> anything else.
>
> --Brian
>
>
>
