apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Travis <jtra...@covalent.net>
Subject Re: Time funniness between HPUX and everyone else
Date Mon, 07 Jan 2002 21:22:10 GMT
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
> 
> 
> 

Mime
View raw message