Tom Lane wrote:
Thomas Lockhart [EMAIL PROTECTED] writes:
Why should we rely on broken glibc and the standard? Why don't we make
our own mktime() and use it on all platforms.
The downside to doing that is that we then take over maintenance of the
code and, more importantly, the
Trond Eivind Glomsrød wrote:
On Tue, 21 May 2002, Lamar Owen wrote:
On Tuesday 21 May 2002 11:04 am, Manuel Sugawara wrote:
I see. This behavior is consistent with the fact that mktime is
supposed to return -1 on error, but then is broken in every other Unix
implementation that I
On Thu, 2002-05-23 at 07:20, Michael Meskes wrote:
The glibc version in the soon to be released Woody
release is 2.2.5.
The version in RHL7.3 is 2.2.5-34. This is not what Debian uses. Maybe
you should read the changelog for the version.
--
---. ,-.
On Fri, 2002-05-24 at 12:03, Peter Eisentraut wrote:
Or does the -34 mean more than just the RedHat version number? The
Debian version is correctly named 2.2.5-6 where the -6 means that this
is the 6th release of glibc 2.2.5 for Debian,
Just for general amusement: I run SuSE's glibc
On Friday 24 May 2002 03:15 pm, Ulrich Drepper wrote:
This is getting silly.
Yes, Ulrich, it is. Very silly. And Red Hat's stance is one of the silliest,
IMHO.
You'll see that the glibc in RHL7.3 contains a lot of the
code from the glibc 2.3 branch. It's not named 2.2.90 because major
On Fri, May 24, 2002 at 12:15:47PM -0700, Ulrich Drepper wrote:
This is getting silly. Does nobody here understand that the release
Yes, but I'm not sure on which side.
number is local for each distribution. Comparing them does not lead to
No, this is simply not true. The version number is
On Sat, 25 May 2002, Michael Meskes wrote:
No, this is simply not true. The version number is what the upstream
gives its release. No more no less. What RH does is becoming as subtly
incompatible a possible. If that's the goal, it doesn't look like free
software for me. Sure all changes are
On Thu, 2002-05-23 at 15:20, Michael Meskes wrote:
On Wed, May 22, 2002 at 10:58:15AM -0700, Ulrich Drepper wrote:
On Wed, 2002-05-22 at 10:51, Lamar Owen wrote:
What isn't funny is Oliver Elphick's results on Debian, running glibc 2.2.5
(same as Red Hat 7.3's version).
This is
On Thu, May 23, 2002 at 09:29:06AM -0700, Ulrich Drepper wrote:
On Thu, 2002-05-23 at 07:20, Michael Meskes wrote:
The glibc version in the soon to be released Woody
release is 2.2.5.
The version in RHL7.3 is 2.2.5-34. This is not what Debian uses. Maybe
you should read the
...
But anybody using Unix dates as general dates has leaped into exactly the
same sort of trap that caused people to get so paranoid about Y2K.
Certainly true. We don't use Unix dates as general dates, we use the
Unix time zone database and API for dates and times within the year
range of
On Fri, 24 May 2002 06:10:39 PDT, the world broke into rejoicing as
Thomas Lockhart [EMAIL PROTECTED] said:
...
But anybody using Unix dates as general dates has leaped into exactly the
same sort of trap that caused people to get so paranoid about Y2K.
Certainly true. We don't use Unix
[EMAIL PROTECTED] writes:
By the way, the seemingly relevant link to look at for TZ info is
http://www.twinsun.com/tz/tz-link.htm, linking to the data used by
various Unix implementations.
Oh, this is interesting: it claims that
: This database (often called tz or zoneinfo) is used by
Tom Lane wrote:
It seems to me that it'd be really practical to just take what we
need out of this distribution and forgo all dependency on
system-provided timezone databases. And, since there's a mailing
list maintaining it, we could expect someone else to handle updates
;-) ... we'd
Joe Conway [EMAIL PROTECTED] writes:
I don't understand precisely what need to be done, but I'll give it a
shot if you get me pointed in the right direction.
downloads and looks at code
I see that tzcode2002c.tar.gz includes a mktime() function. Is the idea
to pull this out (with just
Michael Meskes writes:
Or does the -34 mean more than just the RedHat version number? The
Debian version is correctly named 2.2.5-6 where the -6 means that this
is the 6th release of glibc 2.2.5 for Debian,
Just for general amusement: I run SuSE's glibc 2.2.5-38 which contains
neither the
Tom Lane wrote:
Well, that's the zeroth-order approximation. We should take the
opportunity to get out from under the mktime()/tzset() API. The real
idea here is to make use of the timezone database info in the ways that
Postgres needs. Some things that are not good about mktime()/tzset():
...
Well, this does sound a bit more involved than I was envisioning. There
are a few items wrt SRFs that I should finish first, but I'll come back
to this afterward if no one else does first.
The first cut might be to reproduce the functionality we already have.
That would allow us to
Thomas Lockhart [EMAIL PROTECTED] writes:
The last phase could be extending the API to allow multiple simultaneous
time zones, detection of bad time zones, etc etc. This would involve API
changes or extensions, and breaks compatibility with system-supplied
infrastructure.
One thing that
The last phase could be extending the API to allow multiple simultaneous
time zones, detection of bad time zones, etc etc. This would involve API
changes or extensions, and breaks compatibility with system-supplied
infrastructure.
One thing that wasn't clear to me, but could use
Thomas Lockhart [EMAIL PROTECTED] writes:
The fundamental problem (which of course can have a fundamental solution
;) is that a time zone database built with a 32-bit time_t will have
time zone info through 2038 only (it is a binary file with 32-bit time
fields -- almost certainly anyway).
The last phase could be extending the API to allow multiple simultaneous
time zones, detection of bad time zones, etc etc. This would involve API
changes or extensions, and breaks compatibility with system-supplied
infrastructure.
One thing that wasn't clear to me, but could use
On Fri, 24 May 2002, Peter Eisentraut wrote:
Michael Meskes writes:
Or does the -34 mean more than just the RedHat version number? The
Debian version is correctly named 2.2.5-6 where the -6 means that this
is the 6th release of glibc 2.2.5 for Debian,
Just for general amusement: I
On Thu, May 23, 2002 at 04:42:13AM +0200, Magnus Naeslund(f) wrote:
Some answers on database sizes, if this is any help...
I did du -sh /usr/share/zoneinfo/ on them all.
OpenBSD 3.1, sparc64:
1.3M/usr/share/zoneinfo/
Linux, i686, oldish mandrake (6.x?), glibc 2.1.3:
478k
On Wed, 2002-05-22 at 08:00, Thomas Lockhart wrote:
...
If so, can we get them to champion changes which would comply with the
standard but remove this arbitrary breakage?
Unlikely. They already saw (and participated, at least Ulrich) a thread on
this with Lamar. Their take is this is
On Wed, 2002-05-22 at 10:51, Lamar Owen wrote:
What isn't funny is Oliver Elphick's results on Debian, running glibc 2.2.5
(same as Red Hat 7.3's version).
This is a completely different version. Once Debian updates (in a few
years) they'll get the same result.
If you are misusing
On Wed, 2002-05-22 at 11:23, Tom Lane wrote:
Unix systems have
*always* interpreted time_t as a signed offset from the epoch.
No. This always was an accident if it happens.
Do you
really think that when Unixen were first built in the early 70s, there
was no interest in working with
On Wed, May 22, 2002 at 10:58:15AM -0700, Ulrich Drepper wrote:
On Wed, 2002-05-22 at 10:51, Lamar Owen wrote:
What isn't funny is Oliver Elphick's results on Debian, running glibc 2.2.5
(same as Red Hat 7.3's version).
This is a completely different version. Once Debian updates (in a
On 22 May 2002, Ulrich Drepper wrote:
On Wed, 2002-05-22 at 10:51, Lamar Owen wrote:
What isn't funny is Oliver Elphick's results on Debian, running glibc 2.2.5
(same as Red Hat 7.3's version).
This is a completely different version. Once Debian updates (in a few
years) they'll get the
--=-Z1lifK4QZqKV8kHqHfYT
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Wed, 2002-05-22 at 10:51, Lamar Owen wrote:
What isn't funny is Oliver Elphick's results on Debian, running glibc 2.2=
.5=20
(same as Red Hat 7.3's version).
This is a completely
On 22 May 2002, Ulrich Drepper wrote:
On Wed, 2002-05-22 at 11:23, Tom Lane wrote:
Unix systems have
*always* interpreted time_t as a signed offset from the epoch.
No. This always was an accident if it happens.
Do you
really think that when Unixen were first built in the
On 22 May 2002, Ulrich Drepper wrote:
On Wed, 2002-05-22 at 11:23, Tom Lane wrote:
Unix systems have
*always* interpreted time_t as a signed offset from the epoch.
No. This always was an accident if it happens.
Do you
really think that when Unixen were first built in the early 70s,
On Thu, 23 May 2002 [EMAIL PROTECTED] wrote:
On 22 May 2002, Ulrich Drepper wrote:
On Wed, 2002-05-22 at 11:23, Tom Lane wrote:
Unix systems have
*always* interpreted time_t as a signed offset from the epoch.
No. This always was an accident if it happens.
Do you
On Wed, 2002-05-22 at 02:14, Tom Lane wrote:
=?ISO-8859-1?Q?Trond_Eivind_Glomsr=F8d?= [EMAIL PROTECTED] writes:
Relying on nonstandardized/nondocumented behaviour is a program bug, not a
glibc bug. PostgreSQL needs fixing. Since we ship both, we're looking at
it, but glibc is not the
IIRC the spec is not _really_ broken - it still allows the correct
behaviour :)
Yes.
The fact the ISO spec is broken usually means that at least one of the
big vendors involved in ISO spec creation must have had a broken
implementation at that time.
Right. IBM.
Most likely they have
On Wed, 2002-05-22 at 15:30, Thomas Lockhart wrote:
IIRC the spec is not _really_ broken - it still allows the correct
behaviour :)
Yes.
The fact the ISO spec is broken usually means that at least one of the
big vendors involved in ISO spec creation must have had a broken
Thomas Lockhart writes:
Right. IBM.
Most likely they have fixed it by now ...
Nope, though I don't know for sure. Anyone here have a recent AIX
machine to test?
Well on AIX 4.3.3 the output from Lamar's earlier test program is:
The system thinks 11/30/1969 is a timestamp of -1
and
...
AIX and (I think) Irix.
How do we currently support AIX/Irix ?
Dates and times prior to 1970 have no time zone (they are in GMT, as is
the case for all platforms on dates before 1903 and after 2038). We have
separate regression test results for those platforms.
On Wed, 22 May 2002, Thomas Lockhart wrote:
IIRC the spec is not _really_ broken - it still allows the correct
behaviour :)
Yes.
The fact the ISO spec is broken usually means that at least one of the
big vendors involved in ISO spec creation must have had a broken
implementation
On Wednesday 22 May 2002 01:12 pm, Ulrich Drepper wrote:
On Wed, 2002-05-22 at 08:00, Thomas Lockhart wrote:
If so, can we get them to champion changes which would comply with
the standard but remove this arbitrary breakage?
Unlikely. They already saw (and participated, at least
Ulrich Drepper [EMAIL PROTECTED] writes:
If you are misusing interfaces you get what you deserve. At no time was
it correct to use these functions for general date manipulation. It
always only was allowed to use them to represent system times and there
was no Unix system before the epoch.
On Wednesday 22 May 2002 01:58 pm, Ulrich Drepper wrote:
On Wed, 2002-05-22 at 10:51, Lamar Owen wrote:
What isn't funny is Oliver Elphick's results on Debian, running glibc
2.2.5 (same as Red Hat 7.3's version).
This is a completely different version. Once Debian updates (in a few
This thread is getting pretty annoying rather than constructive. By
the mean time I can see the users of many db's running under linux
loudly complaining.
As a user of both products (glibc and postgres), I would like to see a
good compromise in both sides. For instance: postgreSQL will implement
OK. They must be new guys.
:-) Very funny.
Hey, it worked. Got you out of the woodwork. :))
- Thomas
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister
On Wed, 2002-05-22 at 15:30, Thomas Lockhart wrote:
IIRC the spec is not _really_ broken - it still allows the correct
behaviour :)
Yes.
The fact the ISO spec is broken usually means that at least one of the
big vendors involved in ISO spec creation must have had a broken
...
Why should we rely on broken glibc and the standard? Why don't we make
our own mktime() and use it on all platforms.
The downside to doing that is that we then take over maintenance of the
code and, more importantly, the timezone database.
But it might be the best thing to do. It looks
Tom Lane [EMAIL PROTECTED] wrote:
[snip]
Exactly how much work (and code bulk) would we be taking on? I've
never looked at how big the timezone databases are...
Some answers on database sizes, if this is any help...
I did du -sh /usr/share/zoneinfo/ on them all.
OpenBSD 3.1,
...
Our implementation is broken, then. Thomas, is this fixable for a 7.2.x
release, or something for 7.3?
Our implementation is broken, then is really not a conclusion to be
reached. The de facto behavior of mktime() on all world-class
implementations is to support pre-1970 times. This has
Lamar Owen [EMAIL PROTECTED] writes:
On Monday 20 May 2002 08:08 pm, Manuel Sugawara wrote:
Where would we go to ferret out the source of this bug? More to the
point: we need a test case in C that could expose this as a glibc
bug.
Seems like mktime(3) is having problems with dates
On Tue, 21 May 2002, Lamar Owen wrote:
On Tuesday 21 May 2002 11:04 am, Manuel Sugawara wrote:
I see. This behavior is consistent with the fact that mktime is
supposed to return -1 on error, but then is broken in every other Unix
implementation that I know.
Any other workaround than
On Tuesday 21 May 2002 11:04 am, Manuel Sugawara wrote:
I see. This behavior is consistent with the fact that mktime is
supposed to return -1 on error, but then is broken in every other Unix
implementation that I know.
Any other workaround than downgrade or install FreeBSD?
Complain to Red
On Tuesday 21 May 2002 12:31 pm, Trond Eivind Glomsrød wrote:
On Tue, 21 May 2002, Lamar Owen wrote:
However, as this is a glibc change, other
distributors are very likely to fold in this change sooner rather than
later.
Relying on nonstandardized/nondocumented behaviour is a program
Trond Eivind Glomsrød [EMAIL PROTECTED] writes:
Relying on nonstandardized/nondocumented behaviour is a program bug,
not a glibc bug.
The question is: how this thing didn't show up before? ISTM that
someone is not doing his work correctly.
PostgreSQL needs fixing.
Arguably, however, right
On 21 May 2002, Manuel Sugawara wrote:
Trond Eivind Glomsrød [EMAIL PROTECTED] writes:
Relying on nonstandardized/nondocumented behaviour is a program bug,
not a glibc bug.
The question is: how this thing didn't show up before? ISTM that
someone is not doing his work correctly.
FWIW,
On Tuesday 21 May 2002 03:09 pm, Trond Eivind Glomsrød wrote:
FWIW, I ran the regressions tests some time ago(probably before that
change to glibc) . Since the tests are known
to be broken wrt. time issues anyway (as well as currency, math and
sorting), it's easy to overlook.
The time tests
=?ISO-8859-1?Q?Trond_Eivind_Glomsr=F8d?= [EMAIL PROTECTED] writes:
Relying on nonstandardized/nondocumented behaviour is a program bug, not a
glibc bug. PostgreSQL needs fixing. Since we ship both, we're looking at
it, but glibc is not the component with a problem.
A library that can no
On Tue, 2002-05-21 at 21:31, Trond Eivind Glomsrød wrote:
On Tue, 21 May 2002, Lamar Owen wrote:
On Tuesday 21 May 2002 11:04 am, Manuel Sugawara wrote:
I see. This behavior is consistent with the fact that mktime is
supposed to return -1 on error, but then is broken in every other
On Tue, 2002-05-21 at 18:24, Lamar Owen wrote:
In any case, this isn't just a Red Hat problem, as it's going to cause
problems with the use of timestamps on ANY glibc 2.2.5 dist. That's more
than Red Hat, by a large margin.
I'm running glibc 2.2.5 on Debian and all regression tests pass OK
On Tuesday 21 May 2002 06:09 pm, Oliver Elphick wrote:
On Tue, 2002-05-21 at 18:24, Lamar Owen wrote:
In any case, this isn't just a Red Hat problem, as it's going to cause
problems with the use of timestamps on ANY glibc 2.2.5 dist. That's more
than Red Hat, by a large margin.
I'm
Manuel Sugawara [EMAIL PROTECTED] writes:
+#if 0
/* Only years after 1970 are defined.
If year is 69, it might still be representable due to
timezone differnces. */
if (year 69)
return -1;
+#endif
Hm. If that fixes it, it implies that all the other support for
Lamar Owen writes:
SuSE already does this. I wonder how they've handled this issue with
8.0?
Their glibc doesn't have that problem.
Personally, I think if you need time (zone) support before 1970, obtain
one of the various operating systems that support it. There's little
value in hacking
SuSE already does this. I wonder how they've handled this issue with
8.0?
Their glibc doesn't have that problem.
My strong recollection is that a SuSE guy was the one applying the
change. So this is coming to those systems too. I may not remember that
correctly though...
Personally, I
On Tue, 2002-05-21 at 23:47, Lamar Owen wrote:
Hmmm. Compile and run the attached program. If you get -1, it's the new
behavior. It might be interesting to see the differences here.
$ a.out
The system thinks 11/30/1969 is a timestamp of -176400
$ dpkg -l libc6
...
||/ Name
On Saturday 18 May 2002 12:34 am, Manuel Sugawara wrote:
Something is pretty broken in redhat 7.3 but I'm not sure what and I
don't have time to dig further
Both cases works correctly in Redhat 7.2. Sorry if this is not the
correct forum however an alert is nice for people planning an Redhat
Lamar Owen [EMAIL PROTECTED] writes:
Filed on Red Hat's Bugzilla system as bug# 65227, as I can reliably
reporoduce this bug here, and PostgreSQL 7.2.1 on Red Hat 6.2 on
SPARC does not exhibit the bug.
Thanks for filling that report. I couldn't remember what had forgotten
;-)
Regards,
Lamar Owen [EMAIL PROTECTED] writes:
Where would we go to ferret out the source of this bug? More to the
point: we need a test case in C that could expose this as a glibc
bug.
Seems like mktime(3) is having problems with dates before the
epoch. Attached is the a program to test this. The
On Monday 20 May 2002 08:08 pm, Manuel Sugawara wrote:
Where would we go to ferret out the source of this bug? More to the
point: we need a test case in C that could expose this as a glibc
bug.
Seems like mktime(3) is having problems with dates before the
epoch. Attached is the a
Hi,
Something is pretty broken in redhat 7.3 but I'm not sure what and I
don't have time to dig further
masm@test=# select cast('1967-04-18' as timestamptz);
timestamptz
1967-04-17 18:00:00-06
(1 row)
masm@test=# select cast(cast('1967-04-18' as date) as
67 matches
Mail list logo
