You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jon Travis <jt...@covalent.net> on 2002/05/21 04:47:24 UTC
APR time test failing
My time test is failing. I get a mismatch:
checking localtime explode == GMT implode mismatch
apr_now() 1021948993979908
apr_implode() returned 1021981393979908
error delta was 32400000000
should have been 0
-- Jon
Re: APR time test failing
Posted by Jon Travis <jt...@covalent.net>.
On Tue, May 21, 2002 at 01:01:48AM -0400, Cliff Woolley wrote:
> On Tue, 21 May 2002, Cliff Woolley wrote:
>
> > Index: time.c
> > ===================================================================
> > RCS file: /home/cvs/apr/time/win32/time.c,v
> > retrieving revision 1.32
> > diff -u -d -r1.32 time.c
> > --- time.c 15 Apr 2002 00:01:09 -0000 1.32
> > +++ time.c 21 May 2002 04:41:09 -0000
> > @@ -215,7 +215,6 @@
> > if (days < 0) {
> > return APR_EBADDATE;
> > }
> > - days -= xt->tm_gmtoff;
> > *t = days * APR_USEC_PER_SEC + xt->tm_usec;
> > return APR_SUCCESS;
> > }
>
> Yeah, that was it. The unix and win32 apr_time_exp_get() functions are
> virtually identical except for that line on win32. Does this patch allow
> the tests to pass? I dug up the original email on the subject (thank you
> MARC ;). Credit for this should go to INOUE Seiichiro
> <in...@ariel-networks.com>, who originally reported this in message
> 20020423.004842.122624738.inoue@ariel-networks.com on dev@apr.
Didn't seem to fix it, though maybe my Windows compile-fu is weak. I'll
leave it up to Will.
-- Jon
Re: APR time test failing
Posted by Cliff Woolley <jw...@virginia.edu>.
On Tue, 21 May 2002, Cliff Woolley wrote:
> Index: time.c
> ===================================================================
> RCS file: /home/cvs/apr/time/win32/time.c,v
> retrieving revision 1.32
> diff -u -d -r1.32 time.c
> --- time.c 15 Apr 2002 00:01:09 -0000 1.32
> +++ time.c 21 May 2002 04:41:09 -0000
> @@ -215,7 +215,6 @@
> if (days < 0) {
> return APR_EBADDATE;
> }
> - days -= xt->tm_gmtoff;
> *t = days * APR_USEC_PER_SEC + xt->tm_usec;
> return APR_SUCCESS;
> }
Yeah, that was it. The unix and win32 apr_time_exp_get() functions are
virtually identical except for that line on win32. Does this patch allow
the tests to pass? I dug up the original email on the subject (thank you
MARC ;). Credit for this should go to INOUE Seiichiro
<in...@ariel-networks.com>, who originally reported this in message
20020423.004842.122624738.inoue@ariel-networks.com on dev@apr.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: APR time test failing
Posted by Cliff Woolley <jw...@virginia.edu>.
On Tue, 21 May 2002, Cliff Woolley wrote:
> Didn't someone post a patch for this months ago? I remember it was an
> extraneous timezone add (or subtract, one of the two), and that it was
> in the Win32-specific time code.
Was this it, perhaps?
Index: time.c
===================================================================
RCS file: /home/cvs/apr/time/win32/time.c,v
retrieving revision 1.32
diff -u -d -r1.32 time.c
--- time.c 15 Apr 2002 00:01:09 -0000 1.32
+++ time.c 21 May 2002 04:41:09 -0000
@@ -215,7 +215,6 @@
if (days < 0) {
return APR_EBADDATE;
}
- days -= xt->tm_gmtoff;
*t = days * APR_USEC_PER_SEC + xt->tm_usec;
return APR_SUCCESS;
}
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: APR time test failing
Posted by Cliff Woolley <jw...@virginia.edu>.
On Mon, 20 May 2002, Jon Travis wrote:
> Yeah, it's an interesting one -- apr_time_now() should be GMT though, and
> not have anything to do with timezones (not saying they aren't playing a
> part in this issue, though).
>
> This problem manifested itself when a program I was running on Windows
> had a hard time communicating with a program under UNIX. Both used
> apr_time_now() to determine the current time, and I guess they came up
> with different answers.
Didn't someone post a patch for this months ago? I remember it was an
extraneous timezone add (or subtract, one of the two), and that it was
in the Win32-specific time code.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: APR time test failing
Posted by Jon Travis <jt...@covalent.net>.
On Mon, May 20, 2002 at 11:17:49PM -0500, William A. Rowe, Jr. wrote:
> At 09:51 PM 5/20/2002, Jon Travis wrote:
> >On Mon, May 20, 2002 at 07:47:24PM -0700, Jon Travis wrote:
> > > My time test is failing. I get a mismatch:
> > >
> > > checking localtime explode == GMT implode mismatch
> > > apr_now() 1021948993979908
> > > apr_implode() returned 1021981393979908
> > > error delta was 32400000000
> > > should have been 0
> >
> >Sorry, should have been more thorough.
> >
> >This problem only occurs under Windows for me. Under UNIX the test
> >works fine.
>
> 9 hour delta... evidently we missed timezone data, and then MIS
> compensated for the DST delta [otherwise, where would 9hrs -> PST
> come from... PDT should be 7hrs from GMT, no?]
Yeah, it's an interesting one -- apr_time_now() should be GMT though, and
not have anything to do with timezones (not saying they aren't playing a
part in this issue, though).
This problem manifested itself when a program I was running on Windows
had a hard time communicating with a program under UNIX. Both used
apr_time_now() to determine the current time, and I guess they came up
with different answers.
-- Jon
Re: APR time test failing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 09:51 PM 5/20/2002, Jon Travis wrote:
>On Mon, May 20, 2002 at 07:47:24PM -0700, Jon Travis wrote:
> > My time test is failing. I get a mismatch:
> >
> > checking localtime explode == GMT implode mismatch
> > apr_now() 1021948993979908
> > apr_implode() returned 1021981393979908
> > error delta was 32400000000
> > should have been 0
>
>Sorry, should have been more thorough.
>
>This problem only occurs under Windows for me. Under UNIX the test
>works fine.
9 hour delta... evidently we missed timezone data, and then MIS
compensated for the DST delta [otherwise, where would 9hrs -> PST
come from... PDT should be 7hrs from GMT, no?]
>BTW: I had to add shell32.lib to the link line for the apr tests to
>build. Has anyone been running the testsuite on windows? ;-)
Odd... didn't complain in a bit when I rebuilt last week. Then again, MS
has fun moving things around on occasion. I will drop that into the build
when I dig into the TZ problem tommorow.
Re: APR time test failing
Posted by Jon Travis <jt...@covalent.net>.
On Mon, May 20, 2002 at 07:47:24PM -0700, Jon Travis wrote:
> My time test is failing. I get a mismatch:
>
> checking localtime explode == GMT implode mismatch
> apr_now() 1021948993979908
> apr_implode() returned 1021981393979908
> error delta was 32400000000
> should have been 0
Sorry, should have been more thorough.
This problem only occurs under Windows for me. Under UNIX the test
works fine.
BTW: I had to add shell32.lib to the link line for the apr tests to
build. Has anyone been running the testsuite on windows? ;-)
-- Jon
Re: APR time test failing
Posted by Jon Travis <jt...@covalent.net>.
x86 -- Windows 2000 -- 5.00.2195
(that's "shark" to you, Will.. ;-) )
-- Jon
On Mon, May 20, 2002 at 09:55:02PM -0500, William A. Rowe, Jr. wrote:
> Hardware? OS? Rev level?
>
> At 09:47 PM 5/20/2002, you wrote:
> >My time test is failing. I get a mismatch:
> >
> >checking localtime explode == GMT implode mismatch
> > apr_now() 1021948993979908
> > apr_implode() returned 1021981393979908
> > error delta was 32400000000
> > should have been 0
> >
> >-- Jon
>
>
Re: APR time test failing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Hardware? OS? Rev level?
At 09:47 PM 5/20/2002, you wrote:
>My time test is failing. I get a mismatch:
>
>checking localtime explode == GMT implode mismatch
> apr_now() 1021948993979908
> apr_implode() returned 1021981393979908
> error delta was 32400000000
> should have been 0
>
>-- Jon