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
--------------------------------------------------------
