Re: 7.2 Beta timezone woes

Tom Lane wrote:

> Elein <elein@nextbus.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@nextbus.com
(510)420-3120
www.nextbus.com
    spinning to infinity, hallelujah
--------------------------------------------------------