On Wed, Mar 17, 2021 at 9:54 AM Surafel Temesgen <surafel3...@gmail.com> wrote: > As you mention above whatever the calendar type is we ended up storing an > integer that represent the date so rather than re-implementing every > function and operation for every calendar we can use existing Gerigorian > implementation as a base implementation and if new calendar want to perform > same function or operation it translate to Gregorian one and use the existing > function and operation and translate to back to working calendar. In this > approach the only function we want for supporting a new calendar is a > translator from the new calendar to Gregorian one and from Gerigorian > calendar to the new calendar and may be input/ output function. What do you > think of this implementation?
I'm not sure what the best way of tackling this problem is, but I wanted to mention another possible approach: instead of actually using the timestamptz data type, have another data type that is binary-compatible with timestamptz - that is, it's the same thing on disk, so you can cast between the two data types for free. Then have separate input/output functions for it, separate operators and functions and so forth. 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. -- Robert Haas EDB: http://www.enterprisedb.com
