On fre, 2011-05-27 at 16:57 -0700, Steve Crawford wrote:
> And the second case is already well handled. In fact calendaring is a
> great example. I enter the time for the teleconference and PG nicely
> uses my default timezone to store the point-in-time. When you
> retrieve
> it, it is shown in your timezone and we both pick up the phone at the
> correct time. And if I know I'll be somewhere else at that time, I
> just
> ask for the data in that zone. Altering the data type gains nothing.
How about a recurring appointment that happens every Tuesday whenever it
is 9:00am in California, independent of DST (in California or where ever
the participant actually is). I'm not sure how to solve that within the
SQL framework. You might need to use time with time zone with a
placeholder timezone, and then a rule that date + time with time zone
creates a timestamp with time zone that resolves the time zone for that
particular day.
