1. The timezone data in ref-timezones comes from Unix/Linux, which is why it goes up until 2038, which is "Y2K" in Unix-speak. It is as complete as that data is, and I assume that data's quite complete as it is used when you install RedHat, Mandrake etc ad nauseum, when it asks for your timezone. Is there any particular timezone you feel is missing? To make things even more problematic I do believe the timezone designations themselves are an ISO standard ... they therefore should be complete as of the date of adoption. PG's internal dataset of timezones seems incomplete. Regardless, ref-timezones gives us a way to deal with them that works with both PG and Oracle, since there's no common overlap within the two RDBMS's for us to lean on. Unfortunately. Though Oracle's moving in the direction of supporting SQL 92 timestamps, hmmm ...
2. I don't see any value in allowing folks to enter their own timezone stuff.
3. As far as recurring events goes, study the iCalendar standard for an industry point-of-view on how to handle them. The short story is that you define an event and recurrance interval, then pass along all the relevant timezone information to the calendaring client, which can then do the transformations without pretending to know anything about timezone the originator lives in.
4. Getting this stuff right both in Oracle and PG is tricky. Knowing what I know now, we would've used "timestamp without timezone" for internal storage. But when we began porting, "timestamp" included timezone information and if PG supported "timestamp without timezone" in early days, it wasn't documented clearly (if at all, and to be honest I think this option was added fairly recently). We're living with that decision, which unfortunately makes things more complex. Perhaps in 5.1 we can move away from "timestamp with timezone" and provide upgrade scripts ... it would simplify life, no doubt.
5. In PG you have to understand that timestamps are always displayed with timezone information. Use of the utilities in ref-timezones ought to make life easier but you need to remember to display with the timezone information chopped off or skewed manually to fool the server-local timestamp displaz into showing the user's local timezone.
