Tom Lane wrote:
Thomas Swan <tswan@idigx.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.