Re: date_trunc should be called date_round?

From: Mario Splivalo <mario(dot)splivalo(at)megafon(dot)hr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql <pgsql-sql(at)postgresql(dot)org>
Subject: Re: date_trunc should be called date_round?
Date: 2009-06-30 06:51:26
Message-ID: 4A49B5EE.8030309@megafon.hr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Tom Lane wrote:
> Mario Splivalo <mario(dot)splivalo(at)megafon(dot)hr> writes:
>> But, date_trunc behaves like round function: round(1.9) = 2.
>
> Hmm ... only for float timestamps, and only for the millisec/microsec
> cases.
>
> case DTK_MILLISEC:
> #ifdef HAVE_INT64_TIMESTAMP
> fsec = (fsec / 1000) * 1000;
> #else
> fsec = rint(fsec * 1000) / 1000;
> #endif
> break;
> case DTK_MICROSEC:
> #ifndef HAVE_INT64_TIMESTAMP
> fsec = rint(fsec * 1000000) / 1000000;
> #endif
> break;
>
> I wonder if we should change this to use floor() instead.
>

I guess it's safe, since you don't have negative timestamps (right?) or
parts of timestamps (millisecs/microsecs), so floor() would act as trunc.

Esp. if for the other parts of timestamp (days, hours, ...) it's actualy
truncating, not rounding, i.e.:

date_trunc('minute', '2009-01-01 12:13:50'::timestamp)

would return '2009-01-01 13:13:00', not '2009-01-01 13:14:00'.

One would expect similar behavior for the milli/microsec part.

Now it's truncating, unless dealing with milli/microseconds, where it's
rounding.

Mike

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Jon Norman 2009-06-30 16:43:34 fsync and Windows XP
Previous Message Daniel Gordon 2009-06-30 06:47:42 Recording how a table is used