> 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
Pete Forman <[EMAIL PROTECTED]> writes:
> It is fairly arbitrary what the answer to this question is: if six
> months is subtracted from a to give b, should a.local.hour =
> b.local.hour or should a.utc.hour = b.utc.hour? If you want the
> former then set tm_isdst = -1 before calling mktime.
It'
Tom Lane writes:
> 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
> i
> > 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
> As far as AIX and IRIX are concerned the timezones _are_ the same. No
> variation of rules from year to year is possible. You are not going
> to work out DST rules for earlier years without incorporating third
> party libraries. As I understand it PostgreSQL undertakes to
> calculate dates on
> 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
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 worse on systems
Thomas Lockhart writes:
> > Here is the program. The call to localtime(&t_ago) is redundant
> > and hence the adjustment of t_ago can be skipped. It is in this
> > program as a sanity check.
> > As it stands, this program assumes that the input and resulting
> > date are in the usual UNIX r
> Here is the program. The call to localtime(&t_ago) is redundant and
> hence the adjustment of t_ago can be skipped. It is in this program
> as a sanity check.
> As it stands, this program assumes that the input and resulting date
> are in the usual UNIX range of [1901, 2038]. I presume that t
Thomas Lockhart writes:
> I haven't yet actually fixed the code, but will post patches when
> I've done so (assuming that a fix is possible).
The normalization in this example program which subtracts 34 years
seems to work OK. I've run it on AIX, IRIX, Linux and Solaris. Some
examples follow.
> I have machines running AIX 4.1.5, 4.2.1, and 4.3.3 if you would like
> to send me your test programs.
I haven't yet actually fixed the code, but will post patches when I've
done so (assuming that a fix is possible).
- Thomas
> > 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
Thomas Lockhart writes:
> > 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
> 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 see in the Linu
> The time zone is now evaluated in the time zone of the result, rather
> than the input, using system support routines from libc.
Ok, I have the answer.
On AIX mktime(3) leaves tm_isdst at -1 if it does not have timezone
info for that particular year and returns -1.
>From man page:
T
On Tue, Jan 09, 2001 at 05:05:34PM +, Thomas Lockhart wrote:
> > What I do not understand is, that I thought a time in december cannot be
> > affected by such math because it is clearly not in the daylight savings
> > months of the year ? Also I thought that you recognize daylight savings
> >
> What I do not understand is, that I thought a time in december cannot be
> affected by such math because it is clearly not in the daylight savings
> months of the year ? Also I thought that you recognize daylight savings time
> by the PDT instead of PST, and PostgreSQL shows a result with PST as
> > On AIX timestamp and horology regression fails in current, because
> > timestamp - interval for result timestamps that are before
> 1970 (epoch ?)
> > are off by one hour. I think this is not an issue for an
> adapted expected file,
> > but a new (in 7.1beta) bug. But I am at no means an ex
41 matches
Mail list logo
