On Tue, 2002-06-11 at 18:36, Josh Berkus wrote:
> Karel,
>
> > The to_interval() will have another (you wanted) behaviour.
>
> Please, please, please do not use to_interval for text formatting of
> intervals.
If he meant what _I_ described then this was exactly that, i.e.
converting (string,
> > I already said it. The to_char() is 'tm' struct interpreter and use
> > standard internal PG routines for interval to 'tm' conversion.
> The point is it should _not_ do that for interval.
I use the tm structure to hold this structured information. I *think*
that Karel's usage is just what i
> > fduch=> SELECT to_char('100days'::interval, '-MM-DD HH24:MI:SS');
> > -
> > -00-10 00:00:00
> I already said it. The to_char() is 'tm' struct interpreter and use
> standard internal PG routines for interval to 'tm' conversion. We can
> talk about why 100days is
On Tue, Jun 11, 2002 at 09:36:39AM -0700, Josh Berkus wrote:
> Karel,
>
> > The to_interval() will have another (you wanted) behaviour.
>
> Please, please, please do not use to_interval for text formatting of
> intervals. It's very inconsistent with the naming of other conversion
> functio
Karel,
> The to_interval() will have another (you wanted) behaviour.
Please, please, please do not use to_interval for text formatting of
intervals. It's very inconsistent with the naming of other conversion
functions, and will confuse the heck out of a lot of users. As well as
messing u
On Tue, Jun 11, 2002 at 06:22:55AM -0700, Thomas Lockhart wrote:
> > > fduch=> SELECT to_char('100days'::interval, '-MM-DD HH24:MI:SS');
> > > -
> > > -00-10 00:00:00
> > I already said it. The to_char() is 'tm' struct interpreter and use
> > standard internal PG rou
On Tue, 2002-06-11 at 11:21, Karel Zak wrote:
> On Tue, Jun 11, 2002 at 11:16:13AM +0200, Hannu Krosing wrote:
> > On Tue, 2002-06-11 at 09:34, Karel Zak wrote:
>
> > > I think, we can keep this behaviour for to_char(), the good thing
> > > is that you can formatting interval to strings that se
On Tue, 2002-06-11 at 11:31, Karel Zak wrote:
> On Tue, Jun 11, 2002 at 12:37:09PM +0400, Fduch the Pravking wrote:
>
> > And 'DD' is defined as in range 1..31...
> > What if I try to select '100 days'?
> >
> > fduch=> SELECT to_char('100days'::interval, '-MM-DD HH24:MI:SS');
> >to_
On Tue, Jun 11, 2002 at 12:37:09PM +0400, Fduch the Pravking wrote:
> And 'DD' is defined as in range 1..31...
> What if I try to select '100 days'?
>
> fduch=> SELECT to_char('100days'::interval, '-MM-DD HH24:MI:SS');
>to_char
> -
> -00-10 00:00:00
I alre
On Tue, Jun 11, 2002 at 11:16:13AM +0200, Hannu Krosing wrote:
> On Tue, 2002-06-11 at 09:34, Karel Zak wrote:
> > I think, we can keep this behaviour for to_char(), the good thing
> > is that you can formatting interval to strings that seems like
> > standard time (15:10:33), etc.
>
> But in
On Mon, Jun 10, 2002 at 03:43:34PM +0200, Karel Zak wrote:
> On Mon, Jun 10, 2002 at 04:26:47PM +0200, Hannu Krosing wr ote:
> > perhaps show them with the precision specified and keep data for bigger
> > units in biggest specified unit.
> >
> > to_char('2years 1min 4sec'::interval, 'MM SS'); ==>
On Tue, 2002-06-11 at 09:34, Karel Zak wrote:
> On Mon, Jun 10, 2002 at 07:18:44PM +0200, Hannu Krosing wrote:
>
> OK, I add to_interval() to may TODO (but it's unsure for 7.3).
>
> > hannu=# select to_char('33s 15h 10m 5months'::interval, '.MM.DD
> > HH24:MI:SS');
> >to_char
On Mon, Jun 10, 2002 at 07:18:44PM +0200, Hannu Krosing wrote:
OK, I add to_interval() to may TODO (but it's unsure for 7.3).
> hannu=# select to_char('33s 15h 10m 5months'::interval, '.MM.DD
> HH24:MI:SS');
>to_char
> -
> .05.00 15:10:33
> (1 row)
Karel, Hannu,
To be perfectly honest, I was looking at my 7.1 documentation (courtesy
of DOSSIER) and hadn't realized that 7.2's implementation had got as
far as a function. I had tried to_char(interval) on 7.2.1, received
what looked like gibberish in return, and assumed that it was
unimplement
On Mon, 2002-06-10 at 15:43, Karel Zak wrote:
> On Mon, Jun 10, 2002 at 04:26:47PM +0200, Hannu Krosing wrote:
>
> > > to_char() convert interval to 'tm' and make output like this struct,
> >
> > My point is that to_char-ing intervals by converting them to dates is
> > non-intuitive.
> >
> >
On Mon, Jun 10, 2002 at 04:26:47PM +0200, Hannu Krosing wrote:
> > to_char() convert interval to 'tm' and make output like this struct,
>
> My point is that to_char-ing intervals by converting them to dates is
> non-intuitive.
>
> It is really confusing to say that an interval of 5 months = "
On Mon, 2002-06-10 at 10:49, Karel Zak wrote:
>
> > > I'm _sure_ that to_char() is there for interval.
> > >
> > > testt=# select to_char('33s 15h 10m 5month'::interval, 'HH:MI:SS Month');
> > > to_char
> > >
> > > 03:10:33 May
> > > (1 row)
> >
> > Does "May
> > I'm _sure_ that to_char() is there for interval.
> >
> > testt=# select to_char('33s 15h 10m 5month'::interval, 'HH:MI:SS Month');
> > to_char
> >
> > 03:10:33 May
> > (1 row)
>
> Does "May" make sense for an _interval _ ? (Feb 22 + May = Jul 22)?
>
> Wo
On Mon, 2002-06-10 at 09:58, Karel Zak wrote:
> On Fri, Jun 07, 2002 at 06:48:31PM -0700, Thomas Lockhart wrote:
> >
> > > Proposal #4: Create to_char(INTERVAL, 'format string') Function.
> > > Reason: self-evident, I think.
> >
> > Oh. Didn't know it wasn't already there.
>
> I'm _sure_ tha
On Fri, Jun 07, 2002 at 06:48:31PM -0700, Thomas Lockhart wrote:
>
> > Proposal #4: Create to_char(INTERVAL, 'format string') Function.
> > Reason: self-evident, I think.
>
> Oh. Didn't know it wasn't already there.
I'm _sure_ that to_char() is there for interval.
testt=# select to_char('33
"Josh Berkus" <[EMAIL PROTECTED]> writes:
> Yeah. I'd love to have somebody explain this to me. I noticed when
> zinc was mentioned, but I don't know *what* it is. Care to send me a
> link?
I think http://www.twinsun.com/tz/tz-link.htm is the underlying timezone
database that Thomas is referri
Thomas,
> Please define "a full set of operators". Or do the subsequent
> proposals
> defining new behaviors and some operations constitute that list?
+ - / * < > = and, if appropriate, %
Where support is lacking is * and /
Don't get me wrong. PostgreSQL has the best implementation of
date/tim
> Please give me feedback on this...
> There are a few problems currently with the Interval data type. The biggest
> is that the current rules give us no clear path for implementation of a full
> set of operators. The SQL92 standard is no help here; its implementation is
> unintuitive and extrem
Developers,
Here's part to of my proposal to enhance, improve, and fix Timestamp and
Interval in PostgreSQL. Part I is included after Part II in case everyone
has forgotten it.
Please give me feedback on this. My interest is that I develop calendaring
apps based on Postgresql, and the cur
24 matches
Mail list logo
