Re: date_trunc should be called date_round?
От | Mario Splivalo |
---|---|
Тема | Re: date_trunc should be called date_round? |
Дата | |
Msg-id | 4A49B5EE.8030309@megafon.hr обсуждение исходный текст |
Ответ на | Re: date_trunc should be called date_round? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-sql |
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
В списке pgsql-sql по дате отправления: