> I've been meaning to ask about that, might as well do it now. As you say,
> the DateStyle setting is overloaded for two separate things: default
> output style (ISO, "SQL", Postgres, German), and month/day vs day/month
> setting. This has always confused me (and presumably not only me) and it
> is quite tricky to integrate this into my options work -- there is no
> family of settings for "takes a string input and sets two integer
> variables".
Perhaps it is confusing because it tries to cover (regional) cases we
aren't all familiar with?
> Maybe we could split this up:
> * datetime_output_style: one of ISO, SQL, Postgres, German
> (In fact, if we wanted, we could also make this an arbitrary to_char()
> format string. If it's empty we default to ISO, if it's set then we pass
> it right on to to_char. I guess then we'd need separate parameters for
> date and time though.)
I've been pretty resistant to having a fully-tailorable native output
capability, since it would be possible to generate date strings which
can not be correctly interpreted on input. It might interact badly with
pg_dump, for example. It might be a bit slower than the current
hard-coded technique.
> * day_before_month: true/false
> We can provide backward compatibility by still accepting SET DateStyle,
> but internally parsing it apart into these two.
"German" doesn't have much meaning with a flipped month/day field. So
these aren't entirely decoupled. We could vote quickly to get rid of it
and hope that those Germans aren't paying attention ;)
I guess that my letting go of what *I* think is important could be or is
or will be necessary for continued progress on the date/time handling.
But stability and predictability is pretty important. Eventually,
perhaps we should get rid of all of the options, insist on ISO-8601 as
the input and output format, and insist that people use to_char() if
they want anything more. But that seems a bit extreme.
- Thomas