| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Marek Läll <lall(dot)marek(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, fcaldasdesou(at)bloomberg(dot)net, PostgreSQL Bug List <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #18445: date_part / extract range for hours do not match documentation |
| Date: | 2024-04-26 19:36:30 |
| Message-ID: | CAKFQuwbzoqKWb9n86sTaOuOp_0_WUfGC0vLHV0kJkyDpHSyHaQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Fri, Apr 26, 2024, 12:28 Marek Läll <lall(dot)marek(at)gmail(dot)com> wrote:
> We tend not to introduce breaking changes if the only motivation is to be
>> consistent.
>>
>
> Other mistakes are minor, but why is time '24:00:00' allowed, and it's
> actually 00:00:00 of the next day, that's something I'd like to read a
> well-argued design decision.
> It's like months 1 through 12, and just in case, we also allow month 13,
> which represents January of the next year. But month 14 is not
> allowed, which could represent February of the next year.
> Could you share the rationale behind this decision?
>
It can be easier to construct "< date 24:00:00" to represent until the end
of date rather than producing "< date+1 00:00:00"
David J.
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2024-04-26 20:19:36 | Re: BUG #18445: date_part / extract range for hours do not match documentation |
| Previous Message | Marek Läll | 2024-04-26 19:27:49 | Re: BUG #18445: date_part / extract range for hours do not match documentation |