| From: | Maxim Orlov <orlovmg(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Daniel Gustafsson <daniel(at)yesql(dot)se>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: to_date()/to_timestamp() silently accept month=0 and day=0 |
| Date: | 2026-11-13 08:16:45 |
| Message-ID: | CACG=eza3QDUSEWQYzNwY+ehQjEjgomem8u-e7qNmFMuj=Qar8w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Hi!
Horology theme is of a bit interest for me, so sorry if I'm too nerdy
here. But somebody should :)
I’ll say right away that, even in its current form, I’m in favor of the
patch being included in Postgres. But several issues have become mixed
up in this thread. Let’s go through them one by one, shall we?
1) Can this behavior be considered a bug?
In my eyes, definitely yes. Our documentation [0] on date/time
formatting patterns states what 0's are not viable for DD or MM.
2) AFAICS, these formats are descended to us from ISO 8601.
Unfortunately, I do not have access to that standard. However, I do
have a national adaptation of it, which explicitly states that months
and days begin at 1, as they refer to a *specific* point in time.
3) The assumption that 0 is a valid value comes from the C language.
We are all accustomed to the fact that the struct tm stores
certain fields using a zero-based count and thus this is acceptable.
In reality, however, fields such as tm_mon and tm_yday store an *offset*
relative to the first month or day. See 7.26.1 "Components of time".
4) Thus, if someone uses 0 as the first month of the year or 0 as the
first day of the month in their application code, they are clearly
mistaken. In all likelihood, they would consider the second month to be
1, and so on. In my view, it’s better to get an error right away than
to have to figure out later why a date was implicitly converted. Or,
at least, it is highly desirable to document such an implicit
conversion.
[0] https://www.postgresql.org/docs/current/functions-formatting.html
--
Best regards,
Maxim Orlov.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Laurenz Albe | 2026-11-13 08:21:58 | Re: BUG #19893: REPLICA IDENTITY FULL: UPDATE/DELETE skipped when a subscriber-only column has a value |
| Previous Message | Staroverov Ilja | 2026-11-13 07:34:10 | Re: VACUUM/ANALYZE double-count the backend's own pending table stats |