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
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
behaviour
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) but the
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 compatible and
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
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 that
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 this
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
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
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
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 there
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
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
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 that
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 this ---
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
it's
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's not
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
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
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 to
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
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:
The
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 Linux
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 is
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
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 expert
at
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 I
27 matches
Mail list logo
