> The other category is run-time behaviour, which is the present case of
> testing whether mktime() behaves a certain way when given certain
> arguments. Another item that has been thrown around over the years is
> whether the system supports Unix domain sockets (essentially a run-time
> behavio
Peter Eisentraut writes:
> What if someone has a binary PostgreSQL package installed, then
> updates his time library to something supposedly binary compatible
> and finds out that PostgreSQL still doesn't use the enhanced
> capabilities?
You are too generous. If someone downloads a binary p
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > > This would seem to be the right answer, but unfortunately Autoconf is not
> > > smart enough to detect marginal cross-compilation cases in all situations.
> > > Someone had zlib installed in a location where gcc would find it (compiles
> > > okay
Ian Lance Taylor writes:
> > This would seem to be the right answer, but unfortunately Autoconf is not
> > smart enough to detect marginal cross-compilation cases in all situations.
> > Someone had zlib installed in a location where gcc would find it (compiles
> > okay) but the run-time linker wo
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor writes:
>
> > An approach I've followed in the past is to use three-way logic. If
> > configuring for a native system, compile and run a program which
> > provides a yes or no answer. When using cross-configuration, set the
> > co
Ian Lance Taylor writes:
> An approach I've followed in the past is to use three-way logic. If
> configuring for a native system, compile and run a program which
> provides a yes or no answer. When using cross-configuration, set the
> configuration variable to ``don't know'' (or, since this a d
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> More importantly, you *should* *not* do these tests in configure because
> these tests will be unreliable in a cross-compilation situation.
> Cross-compilation in this context does not only mean compiling between
> completely different platforms, but
Thomas Lockhart writes:
> I'm not sure I fully appreciate the distinction here. configure will
> check for "behavior" of various kinds, including "behavior assumptions"
> in the PostgreSQL code.
There are two general categories of platform dependencies: One is
compilation system features, for e
> Exactly. What if someone has a binary PostgreSQL package installed, then
> updates his time library to something supposedly binary compatible and
> finds out that PostgreSQL still doesn't use the enhanced capabilities?
> Runtime behaviour checks are done at runtime, it's as simple as that.
I'm
> > I agree that configure is the way to go. What if someone has
> > installed a third party library to provide a better mktime() and
> > localtime()?
>
> Exactly. What if someone has a binary PostgreSQL package installed, then
> updates his time library to something supposedly binary compatib
Pete Forman writes:
> I agree that configure is the way to go. What if someone has
> installed a third party library to provide a better mktime() and
> localtime()?
Exactly. What if someone has a binary PostgreSQL package installed, then
updates his time library to something supposedly binary
Zeugswetter Andreas SB writes:
> The down side is, that I did not do a configure test, and did not
> incooperate IRIX, since I didn't know what define to check.
>
> The correct thing to do instead of the #if defined (_AIX) would be
> to use something like #ifdef NO_NEGATIVE_MKTIME and set th
> > The correct thing to do instead of the #if defined (_AIX) would be to use
> > something like #ifdef NO_NEGATIVE_MKTIME and set that with a configure.
> > Thomas, are you volunteering ?
>
> Actually, I can volunteer to be supportive of your efforts ;) I'm
> traveling at the moment, and don't
> The correct thing to do instead of the #if defined (_AIX) would be to use
> something like #ifdef NO_NEGATIVE_MKTIME and set that with a configure.
> Thomas, are you volunteering ?
Actually, I can volunteer to be supportive of your efforts ;) I'm
traveling at the moment, and don't have the orig
> > > > > Yes, the annoyance is, that localtime works for dates before 1970
> > > > > but mktime doesn't. Best would probably be to assume no DST before
> > > > > 1970 on AIX and IRIX.
> > > >
> > > > That seems like a reasonable answer to me, especially since we have
> > > > other platforms tha
> > > > Yes, the annoyance is, that localtime works for dates before 1970
> > > > but mktime doesn't. Best would probably be to assume no DST before
> > > > 1970 on AIX and IRIX.
> > >
> > > That seems like a reasonable answer to me, especially since we have
> > > other platforms that behave tha
> > > Yes, the annoyance is, that localtime works for dates before 1970
> > > but mktime doesn't. Best would probably be to assume no DST before
> > > 1970 on AIX and IRIX.
> >
> > That seems like a reasonable answer to me, especially since we have
> > other platforms that behave that way. How
> > Yes, the annoyance is, that localtime works for dates before 1970
> > but mktime doesn't. Best would probably be to assume no DST before
> > 1970 on AIX and IRIX.
>
> That seems like a reasonable answer to me, especially since we have
> other platforms that behave that way. How can we do th
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> Yes, the annoyance is, that localtime works for dates before 1970
> but mktime doesn't. Best would probably be to assume no DST before
> 1970 on AIX and IRIX.
That seems like a reasonable answer to me, especially since we have
other platforms
> Pete Forman <[EMAIL PROTECTED]> writes:
> > Thinking about that a bit more, I think that tm_isdst should not be
> > written into.
>
> IIRC, setting isdst to -1 was necessary to get the right
> behavior across
> DST boundaries on more-mainstream systems. I do not think it's
> acceptable to do
> > As I see it, the Linux results are also not 100 % correct
> in respect to dates
> > before 1970. (based on assumption that Solaris is correct)
> > <| Sat May 10 23:59:12 1947 PST
> > >| Sat May 10 23:59:12 1947 PDT
> > Was 1947 PDT or PST ? In eighter case one result is one h
> As I see it, the Linux results are also not 100 % correct in respect to dates
> before 1970. (based on assumption that Solaris is correct)
> <| Sat May 10 23:59:12 1947 PST
> >| Sat May 10 23:59:12 1947 PDT
> Was 1947 PDT or PST ? In eighter case one result is one hour off, Solar
Pete Forman writes:
> One workaround would be to add 4*n to tm_year and subtract (365*4+1)
> *24*60*60*n from the time_t returned. (All leap years are multiples
> of 4 in the range 1901 to 2038. If tm_wday is wanted, that will need
> to be adjusted as well.)
FWIW, that should be to add 28*n
Zeugswetter Andreas SB writes:
> Try the attachment with negative values, and tell us whether mktime
> returns anything other that -1. Do you have an idea how else we
> could determine daylight savings time ?
mktime always returns -1 for tm's that might expect to return a
negative number. In
> > > > On AIX mktime(3) leaves tm_isdst at -1 if it does not have timezone
> > > > info for that particular year and returns -1.
> > > > The following code then makes savings time out of the -1.
> > > > tz = (tm->tm_isdst ? (timezone - 3600) : timezone);
> > > Hmm. That description is consista
> > > On AIX mktime(3) leaves tm_isdst at -1 if it does not have timezone
> > > info for that particular year and returns -1.
> > > The following code then makes savings time out of the -1.
> > > tz = (tm->tm_isdst ? (timezone - 3600) : timezone);
> > Hmm. That description is consistant with wha
> > On AIX mktime(3) leaves tm_isdst at -1 if it does not have timezone
> > info for that particular year and returns -1.
> > The following code then makes savings time out of the -1.
> > tz = (tm->tm_isdst ? (timezone - 3600) : timezone);
>
> Hmm. That description is consistant with what I se
27 matches
Mail list logo
