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
> > > implementati
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
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, 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 g
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 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 a
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 i
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 amusem
> > > 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
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
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
...
> 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 (opt
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
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
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.
>
> I see that tzcode2002c.tar.gz includes a mktime() function. Is the idea
> to pull this out (with just whatever support it needs
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
> ;-) ... w
[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 sev
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 us
...
> 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 o
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
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).
> >
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 h
> 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
> --=-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 comp
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 th
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
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 update
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 p
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 interfa
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 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
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
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 timezone database.
>
...
> 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 l
> 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 hav
> > 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 YourE
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
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
>
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 epo
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
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
> > impl
...
> > 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.
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
a
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
>
> 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 hav
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
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
> > 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,
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
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 sup
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
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
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
=?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 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 tes
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 correct
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, ri
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 prog
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 R
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 workarou
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 probl
...
> 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 ha
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
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.
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,
M
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 Red
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 timesta
68 matches
Mail list logo
