Robert Haas <robertmh...@gmail.com> writes:
> It's not very obvious how to scale this kind of approach to a wide
> variety of calendar types, and as Thomas says, it would much cooler to
> be able to handle all of the ones that ICU knows how to support rather
> than just one. But, the problem I see with using timestamptz is that
> it's not so obvious how to get a different output format ... unless, I
> guess, we can cram it into DateStyle. And it's also much less obvious
> how you get the other functions and operators to do what you want, if
> it's different.
Yeah, I'm afraid that it probably is different. The most obvious
example is in operations involving type interval:
select now() + '1 month'::interval;
That should almost certainly give a different answer when using a
different calendar --- indeed the units of interest might not even
be the same. (Do all human calendars use the concept of months?)
I don't feel like DateStyle is chartered to affect the behavior
of datetime operators; it's understood as tweaking the I/O behavior
only. There might be more of a case for letting LC_TIME choose
this behavior, but I bet the relevant standards only contemplate
Gregorian calendars. Also, the SQL spec says in so many words
that the SQL-defined datetime types follow the Gregorian calendar.
So on the whole, new datatypes and operators seem like the way
to go. I concur that if ICU has solved this problem, piggybacking
on it seems more promising than writing our own code.
regards, tom lane
