On Mon, Dec 29, 2014 at 12:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
David G Johnston <david.g.johnston@gmail.com> writes: > Tom Lane-2 wrote >> There is a warning against combining IYYY with MM/DD, but it's buried >> in trivia far down the page.
> Can we move this warning/notice into code? Basically warn/disallow > IYYY-MM-DD (and similar) as a valid format?
> And why not make it an error. If someone really needed to output mixed > modes they would be able to concatenate the two halves together to get the > desired result so it isn't like we are making it impossible to accomplish - > but the typical mistake goes away.
I would say no, and no. It's not at all unreasonable to want to print "YYYY-MM-DD (IYYY-IDDD)" or something like that. And even if we think it's dumb, it's not to_char()'s place to tell people they can't print silly combinations. One could argue in fact that the only reason for to_char() to live at all is to print "silly" combinations --- otherwise, you might as well just cast your timestamp to text.
I didn't suggest "YYYY-MM-DD (IYYY-IDDD)" should throw an error...we can be more conservative/targeted than that.
Anyway, I get your point though you know as well as I do that documentation isn't always the answer. The OP on this issue likely figured he was using the correct format because up until today it was returning the correct result. Its easy enough in hindsight to now look at the documentation and see why he was wrong but it doesn't fix the fact that the code now needs to be fixed when a format specification error would have prevented this simple misunderstanding - strictly using IYYYY-MM-DD instead of YYYY-MM-DD.
Anyway, on the documentation side splitting up the single large table into separate "calendar" tables would make the distinction clearer and also group like specifications together. I would go so far as to repeat those items that can be used with more than one calendar and so make each table self-sufficient. The wording change may further help but breaking out and describing the nuances of the different calendar interpretations of a given point-in-time would add a visual separation for the reader.