I'm having my application checking the database for expired members.
I'm using:UPDATE members SET enabled=0 WHERE now() >= time
That runs every 30 seconds. It was first running at 10 seconds but I didn't know if that was an issue so I made it 30 seconds instead. That's the only thing I have running and my timestamp goes from the time I set and sets it to the time the SQL command is executed. Is there something I'm doing wrong?
Isn't this the expected result? You check the timestamp compared to now() (now() is always greater than time ) and you always update the field. The timestamp is updated also that' s why you get the execution time.
Related
I am using NOW() and the 'datetime' data type. Getting correct date but incorrect time. Like 50 mins earlier time from the current time.How to save the accurate time of the time zone.
eg: SELECT NOW()
This query gives 2021-08-19 17:40:17. But the actual time in my zone was 2021-08-19 17:45:17
Does anyone have any idea why this five minutes difference occurs?
It was a problem with the MySQL machine. It is five minutes slow. Solved the issue by adding five minutes in the insert query. now() + interval 5 minute
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?
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.
I have a dateAdded field that is a DATETIME type. I'm trying the query
SELECT * FROM table WHERE dateAdded > now() - interval 30 minute
It returns 0 rows even though there are a lot of rows created within 30 minutes. When I switch the greater than sign to a less than sign every row in the table is returned. I am using MySQL 5.6.28 and an InnoDB table. What reason could cause this not to work? I am doing a similar query on other tables with a DATETIME type and it works fine.
There seems to be a difference between the timezone used on the column (i.e. application inserting dateAdded data) and the timezone used on the client side issuing the query.
SELECT NOW() - INTERVAL 30 MINUTE proved that difference.
I want to UPDATE my data in scheduled time. My problem is that I cant equal the date that I enter in my database in the current real time date. For example, I have 2015/24/9 19:50:00 in my database, now I want to equal it to the current real time date so that I can update a specific row in the database. If I don't do that, the amount field will just multiply 5 in every row. I want to multiply the amount by 5 in a specific row and time
Code:
CREATE EVENT myeventsdasa11s
ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 1 MINUTE
ON COMPLETION PRESERVE
DO
UPDATE messagesd
SET amount = amount*5
WHERE DATE = (the the current real time date);
DATETIME and TIMESTAMP values are, like floating-point values, difficult to compare for numerical equality. In other words, if it happens that NOW() = datetimestamp, it's a lucky accident. This is especially true when processing events: the event actually starts to run shortly after the scheduled time.
So, instead of saying something like this
`DATE` = NOW()
say something like this
`DATE` BETWEEN NOW() - INTERVAL 10 SECOND
AND NOW() + INTERVAL 10 SECOND
Of course, such a narrow time interval makes you critically dependent on the time accuracy of the event scheduler. You'd be better off adding a LAST_UPDATED column of DATETIME type to your table, then doing this update.
UPDATE messagesd
SET amount = amount * 5,
LAST_UPDATED = `DATE`
WHERE `DATE` >= NOW() - INTERVAL 1 MINUTE
AND (`DATE` > LAST_UPDATED OR LAST_UPDATED IS NULL)
That way, every time your event runs you'll update all the rows that are due for update, but haven't yet been updated. This is not dependent on the precise time an event runs. The - INTERVAL 1 MINUTE allows the event to be up to a minute late running and still function correctly.
If you need to schedule another update for the future for a particular row, change the value of the DATE column but don't touch the LAST_UPDATED column.
Are you just looking for CURDATE()?
CREATE EVENT myeventsdasa11s
ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 1 MINUTE
ON COMPLETION PRESERVE
DO
UPDATE messagesd
SET amount = amount * 5
WHERE DATE = CURDATE();
If you need the current real date time use mysql NOW()
CREATE EVENT myeventsdasa11s
ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 1 MINUTE
ON COMPLETION PRESERVE
DO
UPDATE messagesd
SET amount = amount*5
WHERE DATE = NOW();
I am using version 14.4 of mysql and I am trying to execute the following query:
SELECT TIMESTAMPDIFF(MINUTE, MINUTE(NOW()), NOW())
This should return a timestamp that is on the current hour, but it's always returning null. TIMESTAMPADD works just fine, I am only having trouble with this function. I have looked for answers to this problem through google and mysql documentation but I couldn't find anything.
Does anyone have any an idea on what's going wrong?
My full goal is a query that returns how many minutes are left from now until 5 of the next hour. For example. If its 1:30, our target time is 1:55, so the query would return 25
If you want the hour
SELECT CURTIME()
That query you posted is absurd,or be more clear about what you want.
I believe you're trying to floor the current UNIX timestamp to the current hour? If so, why not be explicit about it?
SELECT UNIX_TIMESTAMP() - UNIX_TIMESTAMP() % 3600;
Based on your edits, you can also calculate the difference to the 5 minute mark preceding the next hour as follows:
SELECT MINUTE( TIMEDIFF(
NOW(),
FROM_UNIXTIME( UNIX_TIMESTAMP() - UNIX_TIMESTAMP() % 3600 + 3600 - 5*60 )
) );
This is just a proof-of-concept query; I haven't yet accounted for rounding the current time to the minute (because I don't know if you want to go up or down), nor handled the edge case where the current time is within 5 minutes of the next hour already (e.g. 1:59).