I have stored DATETIME values in MySQL8 which are all UTC. In my case that is -2h. The Ubuntu 20. Server runs on local time and there is a replica also running on local time.
While doing a cron job I realized that the query never returns results due to the time zone shift:
SELECT *
FROM TABLE
WHERE
r.FOUND >= NOW() - interval 1 minute
How can this query be altered to reflect UTC timezone? I am querying with Python but also within other environments (e.g. Grafana). Also the output should be in the timezone of the user.
Related
I'm new to Grafana and MySQL, .
I have an IoT device sending data every 1 second to an Amazon RDS Aurora database running with MySQL (db.t3.small). With Grafana, I added the RDS Datasource and created a Dashboard to visualize a sensor value on a chart (5 minutes of data displayed, so 300 values).
I noticed that for the first hours, the queries run fast and the dashboard refreshes in less of a second.
However, after 24 hours of data sent to the database, it takes more than 20 seconds to refresh the dashboard. I tried with a Unix timestamp type stored as an integer and with the TIMESTAMP type of MySQL, but I got the same problem. Here is my query:
SELECT
ts_timestampFormat AS "time",
LAeq
FROM testsGrafanaTable
WHERE
$__timeFilter(ts_timestampFormat ) AND
station_id = 'station-1'
ORDER BY ts_timestampFormat
Could you help me to understand why this is happening? Is this related to the query? Or to the database performance?
How I can get a faster query?
I also tried to use a time range in the WHERE statement, ts_timestampFormat >= $__timeFrom() AND ts_timestampFormat <= $__timeTo() AND, but I got the same issue.
Thanks!
I am developing a mobile application. From the application calls are made to a web service which runs different queries based on mode (?mode=xx)
In some of those queries I use date functions like DATE(NOW()).
The data stored in the MySQL database is stored in GMT-7 (Mountain Time Canada).
I have yet to register a domain/host for this web service but when I do lets say it is hosted in a different city such as Toronto (which is GMT-5 - 2 hours ahead). Then at 10:05pm Mountain Time Canada a user uses the application to send a web request call which has a query like:
SELECT DATE(NOW())
Because the server is hosted in Toronto, that will return tomorrow's date, even though where the user is it is the day before and the application shows data based on the current day.
Anyone have any ideas on this?
Edit:
SYSTEM
2015-01-29 16:19:48
2015-01-29 23:19:48
is the result of running the query select ##time_zone, now(), utc_timestamp()
The queries deal with date (yyyy-mm-dd) and time (hh:mm:ss) column type.
You ran this time-diagnostic query on your MySQL server.
select ##time_zone, now(), utc_timestamp()
It's clear from your local time and utc time that your server machine's system time zone setting is 'Canada/Mountain', and the MySQL server software doesn't have its own timezone setting.
If you pick up your tables and move them unchanged to a server in some nearby timezone, you can update your software always to issue the command
set time_zone = 'Canada/Mountain';
right after you connect from your software. This will make your new MySQL connection behave like your current one does time-zone-wise. If you own the MySQL server you can set its default time zone according to the directions on this page. http://dev.mysql.com/doc/refman/5.5/en/time-zone-support.html
Now, here's the story about time data types. DATE, TIME, and DATETIME are all timezone-ignorant. Once you've stored a date/time value you'll get it back the same value even if you change your timezone settings.
The TIMESTAMP data type is timezone-sensitive. Those data items are always stored in UTC, also known as Z, time, formerly known as Greenwich Mean Time. They're always converted to UTC upon being stored, and always converted back upon being retrieved.
The builtin functions for getting current date and time (NOW() and friends) are timezone-sensitive. They'll yield values in local time. The exceptions are the three functions starting with UTC_ which yield values in UTC time.
Many MySQL multi-time-zone applications use the following operational discipline:
Ask each user for a user-preference time zone, or figure it out from some other bit of personal data about the user. (Telephones have this information provisioned into them from the network.) Store that as a zoneinfo-friendly time zone descriptor ('America/New_York', 'Canada/Mountain', 'Europe/Vienna', etc) on the user's behalf.
Upon establishing a MySQL session on behalf of the user, set the user's time zone with a set time_zone query like the one shown above. You should do this right after your connect operation.
Store dates and times for users into TIMESTAMP data types. They'll get converted to UTC as they're stored.
Retrieve them as needed. They'll get converted back to local time.
The idea is that your user's timezone is part of her context. This works well, because if user A is in Vancouver and user B in Halifax, and for some reason user B views user A's time data, it will be shown to B in Atlantic time more-or-less automatically.
It's also good because it deals transparently with the global vagaries of daylight-to-standard time changing. A timestamp from last summer will be displayed in last summer's local time.
Many managers of servers for global use set their system server time, or their MySQL default time zone, to UTC. (Yours doesn't.)
Another way to handle all this is the way in which you've started. Pick a time zone and store your timestamps with respect to that time zone. It's best if you pick a timezone that doesn't alternate between daylight and standard time in that case. Then, when storing times into the database, convert explicity. You'd store times from users in Ottawa by doing something like this.
INSERT INTO tbl (appt) VALUES ( 'whatever-time' - INTERVAL 120 MINUTE)
and you'd get the values out the same way. This is error-prone but you can make it work.
Finally, you can do your conversions yourself.
If you want to know how many minutes of offset there are between some arbitary timezone and UTC, try these two queries.
set time_zone = 'Canada/Atlantic';
select timestampdiff(minute, utc_timestamp(), now());
At this time of year that gives back -240, which is -4:00. You need to use minutes rather than hours because of half-hour or quarter-hour timezone offsets in some countries.
Finally, watch out. TIMESTAMP data types don't represent times before 1970. And, on my MariaDB 10.0 instance it appears to go to hell in a bucket right after 2038-01-19T03:14:07 UTC when the time rolls over out of 32 bits.
I'm trying to set the timezone of a mysql database (5.6.10) that i'm using for development to UTC timezone. Currently the server's timezone is set to an offset of "+00:00", which I presume is using my systems local time as reference.
I could of course set an appropriate offset here, but this has the disadvantage that I need to update this offset when daylight savings time changes.
I can't find a way to just set the timezone to UTC, is there a way to do this?
(I'm converting times back and forth between utc and the mysql's timezone in my application, but i'd really like to have the same times in my database)
I have a MySQL database that is set to a local time zone. Times are inserted as UTC time although the database uses a different time zone. I would like to change the time zone to UTC on the MySQL server. I have found documentation on how to do this, but am reluctant as I do not know if that would also change the values that are already stored in the Database.
My Question: Will changing the time zone of a MySQL server also change the values that are already stored?
In principle it shouldn't. There are various reasons why it shouldn't change, depending on the type of your values : mostly DATETIME and TIMESTAMP.
DATETIME values are never converted, so they are independent of the time zone.
TIMESTAMP values are converted (direct quote from the manual here --- I assume you have a fairly recent version of MySQL) "from the current time zone to UTC for storage, and back from UTC to the current time zone for retrieval. (This does not occur for other types such as DATETIME.) By default, the current time zone for each connection is the server's time. The time zone can be set on a per-connection basis. As long as the time zone setting remains constant, you get back the same value you store. If you store a TIMESTAMP value, and then change the time zone and retrieve the value, the retrieved value is different from the value you stored. This occurs because the same time zone was not used for conversion in both directions." (from http://dev.mysql.com/doc/refman/5.5/en/datetime.html).
So in both cases the data actually stored on the server does not change (which is as it should be), but the values that your queries will show may be different before and after.
It depends on whether you are using TIMESTAMP or DATETIME columns to store your timestamps.
TIMESTAMP times are translated automatically from local time (precisely: from the connection's time zone setting) to UTC time when they are stored in tables to MySQL. They're translated from UTC to local time when they are retrieved.
But DATETIME timestamps are stored and retrieved exactly as your application presented them to MySQL. So, if you change your default timezone to UTC and then retrieve your TIMESTAMP values, you'll get them back in UTC. So they will look like they changed. But what has changed is the automatic translation.
Changing the MySQL default timezone does not alter any table contents.
You can experiment with this by issuing the following command when connecting to your MySQL.
SET time_zone = '+0:00';
That will change your connection's time zone setting without changing anything else.
Be careful when reconfiguring a production server that you know what you're doing: You say your "MySQL database ... is set to a local time zone." You need to investigate exactly how that is set up before you change anything. Because here are the settings that can affect things.
(1) the clock setting on the server machine running your MySQL server software.
(2) the timezone setting on that machine.
(3) the default (aka global) timezone setting in your running MySQL server.
In most modern servers the clock is set to the correct UTC time and the timezone setting is set to whatever local timezone your users expect. And, the default timezone setting for your MySQL server is set to that same local timezone. You need to verify that those things are correct.
If your server's time of day flips over automatically and correctly from standard to daylight savings time (yesterday morning in the USA) the first two are probably right.
If you issue this MySQL command: SELECT ##global.time_zone' and get back either your local time zone name orSYSTEMthe third is right. Also issueSELECT NOW()` to double check. If you get the right time of day your system is probably fine. Finally, issue these two commands:
SET time_zone = '+0:00';
SELECT NOW();
If you get the presently correct UTC time from your system, then everything is a known and good state, and you're ready to make the timezone switch.
Make the switch by changing the system_time_zone variable in your MySQL configuration file and restarting your MySQL server. See here for directions:
http://dev.mysql.com/doc/refman/5.1/en/time-zone-support.html
SELECT * , unix_timestamp( NOW( ) ) - unix_timestamp( created ) AS timedif FROM is_meeting_comments WHERE meeting_id_fk=9
This query is used to find out the time difference between when the record was created (CURRENT TIMESTAMP) and when the select query is executed.
This query is return negatives values on remote PC's. While this problem is not apparent when I first tested on my local server. Is this because of different time zones set? But how would this matter, the time should be the same regardless of any PC because its being calculated from the server end.
Why are negative values occurring?
It's likely that it is negative because of timezone differences. The unix_timestamp function assumes the argument is in a local time zone so it will convert it to UTC as part of its conversion process. If "created" is stored as a local time (non UTF) on a pc in a different timezone (or one with a different timezone configured) then the conversion could be off when read back in on a system in a different timezone.
MYSQL can be configured to allow per-connection timezones (so the timezone is the user's timezone, not the database server's timezone) and this can impact the way dates are stored. Check out this page for more details.