Re: time stamp

Tom Lane wrote:

>Thomas Swan <tswan(at)idigx(dot)com> writes:
>
>
>>>No, it won't. If the user has TimeZone set to -05, as he should, then
>>>his input of '2002-06-20 12:00:00' will be read as '2002-06-20 12:00:00-05'.
>>>And it will be displayed to him that way. But if someone else who
>>>has TimeZone set differently looks at the stored value, it will be shown
>>>to them properly converted into their timezone.
>>>
>>>
>>>
>>This can be a problem if the client is a web application in a fixed
>>timezone and the person viewing the results is in a different time zone.
>>
>>
>
>If the webserver sets its session TimeZone according to the end user's
>preference, everything will work just fine. I am not sure how you
>expect Postgres to intuit the proper timezone to use in this scenario
>without any cooperation from the webserver...
>
> regards, tom lane
>
>
I don't expect it to be a postgres problem. What I was referring to was
the ability to design the software [not Postgres] to use the integer
format of the timestamp field. This way you don't have to know the
local timezone of the server where the postgres client [in this case a
PHP script called inside Apache] is. Thus is if my the end user sets
their timezone to be PST [through some preferences], then when I spit a
formatted date string to them I can do the appropriate adjustments in my
code [client] and present it according to their locale. It's not the
prettiest of solutions, but I found that it work with my situtation and
thought it might help the person who was having the problems. I don't
see it as a fault of postgresql, never have. If date transforms are
needed that can be done just as effectively away from the database and
the client database connectivity library.