Re: 7.2 Beta timezone woes

Tom Lane wrote:

> Elein <elein(at)nextbus(dot)com> writes:
>
>>The way it is puts the burden entirely on the client to figure out
>>what timezone the data is for and force the appropriate
>>timezone( 'MST', value) formatting to it for arithmetic and display.
>>
>
> Huh?
>
> It seems like you are entirely missing the point. The idea is that
> the client storing a time value presents it in his local timezone;
> the internal storage is an *absolute* time (independent of any timezone
> ... the fact that the internal representation is GMT is merely a remnant
> of 18th-century British imperialism); and any client who asks for the
> value gets it presented in *his* local timezone.
>
> If you think this makes the clients' job harder rather than easier,
> then you're either thinking about it all wrong or you have a very
> peculiar set of requirements. Perhaps you could explain why the above
> mind-set doesn't work for you.
>
> regards, tom lane
>
>

With a client in california, I want to do (timestamptz - time)
where both values are "in MST' and display the results and the
timestamptz in MST time. While still having my client set
to PST.

I have times from various locations that I want to
display in their own timezone. I only know what their
timeszones are when I input them.

Perhaps part of the solution is to input the time as timetz.
Perhaps another is to store the display timezone separately.

Or I may be thinking of this all wrong :-) How would one
display multiple timezones easily in one application?
Any brilliant ideas would be great.

Or maybe I should write a new timestamp_fixedtz type :-)

Thanks,
elein

--
--------------------------------------------------------
elein(at)nextbus(dot)com
(510)420-3120
www.nextbus.com
spinning to infinity, hallelujah
--------------------------------------------------------