Re: The IYYY mess again

On Mon, Dec 29, 2014 at 12:12 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)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.

David J.
​