----- "Ivan Sergio Borgonovo" <mail@webthatworks.it> wrote:
You're not forced to store dates with tz but having a data type that understand tz and support tz operations inside the DB is pretty helpful.
Again... suppose you store datetime in GMT and you want to know who had a beer before 1:00am local time maybe during a DTS change [evil grin]? a tz is not an integer. You can't compute the interval on the PHP side and you don't want to return all the times and filter on the PHP side either.
I have never written an application that needed to answer a time question based on the local time for all rows. Your proposal of using date/time columns in the database doesn't fix it, either. You can't query based on "local time" even if MySQL knows all the timezone data.
Anyway tz support across different DB looks much harder to handle than different date format since the "interface" is much more heterogeneous.
That is also a problem.
Oh, and good luck dealing with your DB server sometimes having a different timezone than your web server.
That's life. Anyway MySQL as well as PostgreSQL provide nifty settings to cope with the problem.
Why cope when you can avoid the problem entirely?