On Thu, Aug 30, 2001 at 04:19:20PM -0700, Brian Pane wrote:
> Here's a revised copy of the patch--same code, but with comments added.
> It depends on the new include file apr/include/arch/unix/internal_time.h.
> --Brian
Committed. Thanks. -- justin
Here's a revised copy of the patch--same code, but with comments added.
It depends on the new include file apr/include/arch/unix/internal_time.h.
--Brian
Index: apr/misc/unix/start.c
===
RCS file: /home/cvspublic/apr/misc/unix/start.c
Roy T. Fielding wrote:
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
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 *complete
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 t
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 com
Roy T. Fielding wrote:
On Wed, Aug 29, 2001 at 10:19:40AM -0400, Greg Marr wrote:
At 10:05 AM 08/29/2001, William A Rowe wrote:
At 07:36 PM 08/28/2001, Roy T. Fielding wrote:
On Tue, Aug 28, 2001 at 03:16:42PM -0700, Brian Pane wrote:
As far as I can tell, the result of the calculation should be
in
On Wed, Aug 29, 2001 at 10:19:40AM -0400, Greg Marr wrote:
> At 10:05 AM 08/29/2001, William A Rowe wrote:
> >> At 07:36 PM 08/28/2001, Roy T. Fielding wrote:
> >> >On Tue, Aug 28, 2001 at 03:16:42PM -0700, Brian Pane wrote:
> >> > > As far as I can tell, the result of the calculation should be
> >
At 10:05 AM 08/29/2001, William A Rowe wrote:
> At 07:36 PM 08/28/2001, Roy T. Fielding wrote:
> >On Tue, Aug 28, 2001 at 03:16:42PM -0700, Brian Pane wrote:
> > > As far as I can tell, the result of the calculation should be
> > > independent of daylight savings (e.g., always 5 for
US/Eastern).
>
At 07:36 PM 08/28/2001, Roy T. Fielding wrote:
On Tue, Aug 28, 2001 at 03:16:42PM -0700, Brian Pane wrote:
> As far as I can tell, the result of the calculation should be
> independent of daylight savings (e.g., always 5 for US/Eastern).
Then the calculation must be wrong, since EDT is -0400. EST
On Tue, Aug 28, 2001 at 03:16:42PM -0700, Brian Pane wrote:
> Roy T. Fielding wrote:
>
> >On Tue, Aug 28, 2001 at 11:15:41AM -0700, Brian Pane wrote:
> >
> >>Here's a new version of the get_offset patch that initializes
> >>the TZ offset from apr_initialize. I've attached the new include
> >>file
Roy T. Fielding wrote:
On Tue, Aug 28, 2001 at 11:15:41AM -0700, Brian Pane wrote:
Here's a new version of the get_offset patch that initializes
the TZ offset from apr_initialize. I've attached the new include
file that it uses, apr/include/arch/unix/internal_time.h
Out of curiosity, what happens
Roy T. Fielding wrote:
On Tue, Aug 28, 2001 at 11:15:41AM -0700, Brian Pane wrote:
Here's a new version of the get_offset patch that initializes
the TZ offset from apr_initialize. I've attached the new include
file that it uses, apr/include/arch/unix/internal_time.h
Out of curiosity, what happens
On Tue, Aug 28, 2001 at 11:15:41AM -0700, Brian Pane wrote:
> Here's a new version of the get_offset patch that initializes
> the TZ offset from apr_initialize. I've attached the new include
> file that it uses, apr/include/arch/unix/internal_time.h
Out of curiosity, what happens when we switch f
On Tuesday 28 August 2001 12:32, Greg Stein wrote:
> On Tue, Aug 28, 2001 at 11:15:41AM -0700, Brian Pane wrote:
> > Here's a new version of the get_offset patch that initializes
> > the TZ offset from apr_initialize. I've attached the new include
> > file that it uses, apr/include/arch/unix/inter
On Tue, Aug 28, 2001 at 11:15:41AM -0700, Brian Pane wrote:
> Here's a new version of the get_offset patch that initializes
> the TZ offset from apr_initialize. I've attached the new include
> file that it uses, apr/include/arch/unix/internal_time.h
I don't like Ryan's suggestion for a whole new
On Tue, Aug 28, 2001 at 11:15:41AM -0700, Brian Pane wrote:
> Here's a new version of the get_offset patch that initializes
> the TZ offset from apr_initialize. I've attached the new include
> file that it uses, apr/include/arch/unix/internal_time.h
+1. This function call has been a thorn in my
Here's a new version of the get_offset patch that initializes
the TZ offset from apr_initialize. I've attached the new include
file that it uses, apr/include/arch/unix/internal_time.h
--Brian
Index: apr/misc/unix/start.c
===
RCS file:
On Tuesday 28 August 2001 10:28, Brian Pane wrote:
> >>Would anybody besides me feel better if we had apr_initialize() call
> >>apr_unix_setup_time() to do this?
> >
> >Apparently :) +1
>
> What's the right way to introduce a declaration for apr_unix_setup_time
> (or should it be apr_setup time in
William A. Rowe, Jr. wrote:
From: "Jeff Trawick" <[EMAIL PROTECTED]>
Sent: Tuesday, August 28, 2001 6:47 AM
[...]
Would anybody besides me feel better if we had apr_initialize() call
apr_unix_setup_time() to do this?
Apparently :) +1
What's the right way to introduce a declaration for apr_unix_set
From: "Jeff Trawick" <[EMAIL PROTECTED]>
Sent: Tuesday, August 28, 2001 6:47 AM
> Brian Pane <[EMAIL PROTECTED]> writes:
>
> > On platforms where neither HAVE_GMTOFF nor HAVE___OFFSET is defined,
> > like Solaris, the function "get_offset" in apr/time/unix/time.c is a
> > bottleneck in time form
Brian Pane <[EMAIL PROTECTED]> writes:
> On platforms where neither HAVE_GMTOFF nor HAVE___OFFSET is defined,
> like Solaris, the function "get_offset" in apr/time/unix/time.c is a
> bottleneck in time formatting.
>
> On these platforms, get_offset ignores its argument; it really computes
> the s
On platforms where neither HAVE_GMTOFF nor HAVE___OFFSET is defined,
like Solaris, the function "get_offset" in apr/time/unix/time.c is a
bottleneck in time formatting.
On these platforms, get_offset ignores its argument; it really computes
the server's offset from GMT, normalized so that it's inde
23 matches
Mail list logo
