X-Original-To: pgsql-sql@postgresql.org Received: from spampd.localdomain (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 6B15C475F00 for ; Wed, 26 Mar 2003 11:34:47 -0500 (EST) Received: from davinci.ethosmedia.com (unknown [209.10.40.251]) by postgresql.org (Postfix) with ESMTP id 9AE5C474E44 for ; Wed, 26 Mar 2003 11:34:46 -0500 (EST) Received: from [63.195.55.98] (HELO spooky) by davinci.ethosmedia.com (CommuniGate Pro SMTP 4.0.2) with ESMTP id 2924099; Wed, 26 Mar 2003 08:34:41 -0800 Content-Type: text/plain; charset="iso-8859-1" From: Josh Berkus Organization: Aglio Database Solutions To: Tomasz Myrta , Peter Childs Subject: Re: Does anyone use TO_CHAR(INTERVAL)? Date: Wed, 26 Mar 2003 08:34:31 -0800 User-Agent: KMail/1.4.3 Cc: pgsql-sql@postgresql.org References: <3E817B63.2040006@klaster.net> In-Reply-To: <3E817B63.2040006@klaster.net> MIME-Version: 1.0 Message-Id: <200303260834.31708.josh@agliodbs.com> Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, hits=-32.4 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_KMAIL autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Archive-Number: 200303/583 X-Sequence-Number: 12621 Tomasz, Peter, > I already know all of these things (look at thread "Formatting > intervals" dated on 2003-03-17). I was just thinking about intervals > idea. Keeping time inside interval is good. Keeping months inside > interval also looks good, but keeping both of them doesn't make sense. > It is impossible to use these fields together without referring them to > some real date. However illogical the current bahavior may seem, it *is* the SQL92/99=20 specification, so we're keeping it.=20=20=20 I personally use INTERVAL heavily for calendaring applications. I got into= a=20 discussion with Thomas Lockhart last year about how INTERVAL treats dayligh= t=20 savings time -- which is seriously problematic from a calendar designer's= =20 perspective -- and was turned down by the core team wanting to change the= =20 behavior. Regrettably, even though the ANSI committee made a few mistakes with=20 DATE/TIME, they *are* the ANSI committee and PostgreSQL as a project is ver= y=20 firmly committed to standards. --=20 Josh Berkus Aglio Database Solutions San Francisco