Selecting dates from MySQL using NOW() with Time Zone mutates results - mysql

Question

I'm using a Laravel application that inserts timestamps based upon 'timezone' => 'America/New_York'. All of my data inserted is the correct date time. Which should be expected. I know that the MySQL's own timezone setting doesn't effect the inserted data.
However, I want to retrieve records from 30 mins ago. But when I use MySQL NOW() function its the wrong time. So I set the time_zone to America/New_York that gives me the correct NOW() but all the record dates have been mutated.
SELECT id, updated_at FROM my_table Where id = 6;
Gives me the correct date in my update_at field;
So to select my records within the past 30 mins is use:
SET #PAST_TIME = DATE_SUB(NOW(), INTERVAL 30 MINUTE);
SELECT id, updated_at, #PAST_TIME as past_time FROM my_table Where updated_at >= #PAST_TIME;
Which returns practically every record in my set and as you can see, the past_time is incorrect (I ran this at 9:31 ET).
Recognizing that the time mysql is out of sync, I set the timezone to
SET time_zone = 'America/New_York';
SET #PAST_TIME = DATE_SUB(NOW(), INTERVAL 30 MINUTE);
SELECT id, updated_at, #PAST_TIME as past_time FROM my_table Where updated_at >= #PAST_TIME;
Which outputs the correct PAST_TIME but all the update_at records are mutated. But it shouldn't return some of those records anyway because the mutated results are greater than PAST_TIME
How do I stop the column mutation? while still being able to select my records?

Answer 1

You can think of a timestamp column as essentially storing a UTC date and time. It really does not matter what the session time zone setting was when the timestamp value was stored if you are initializing it with a function such as now() or current_timestamp(); the date and time will be interpreted in the current time zone and converted to UTC (of course, now() returns a value that is time zone dependent but regardless of what the current session time zone is you should end up with the same UTC date and time after conversion). However, how the timestamp is displayed very much depends on what the current session time zone is, for the timestamp will be converted back from UTC to whatever the current time zone in effect is.
(On the other hand, if you have a datetime column initialized with now() what will be stored will very much depend on the current time zone because there is never any time zone conversion done. But then it will always be displayed the same regardless of what the current session time zone is in effect.)
When you want to retrieve records that were updated within the last 30 minutes, it's natural to have in your query somewhere DATE_SUB(NOW(), INTERVAL 30 MINUTE). When you are comparing NOW() or a value computed from NOW() with a timestamp column, again it should not make any difference what the current time zone is. The timestamp column has implicit time zone information (UTC) and you should retrieve the same records regardless. As I would expect, I see exactly the same id values being retrieved before and after you set the America/New_York time zone (one might see some difference due to the time lapse between the two queries; fewer rows might now have been updated in the last 30 minutes). The difference, which is to be expected, is how the dates and times are displayed.
You do want to set the America/New_York time zone just so the dates and times jive with your local time. But you should still be getting the same records regardless.