From: Mario Splivalo <mario.splivalo@megafon.hr>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql <pgsql-sql@postgresql.org>
Subject: Re: date_trunc should be called date_round?
Date: Tue, 30 Jun 2009 08:51:26 +0200
Message-ID: <4A49B5EE.8030309@megafon.hr> (raw)
In-Reply-To: <11724.1246285520@sss.pgh.pa.us>
References: <4A487F94.3070303@megafon.hr>
<11724.1246285520@sss.pgh.pa.us>
Tom Lane wrote:
> Mario Splivalo <mario.splivalo@megafon.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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: mario.splivalo@megafon.hr, tgl@sss.pgh.pa.us
Subject: Re: date_trunc should be called date_round?
In-Reply-To: <4A49B5EE.8030309@megafon.hr>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox