When exporting a file through phpMyAdmin some timestamps are put back an hour. How may I prevent this? I do not want timestamps tampered with. Here's a screenshot for the curious (see the dates.)
I believe the cause may be the SET time_zone = "+00:00"; that is added to every export file.
Is this suppose to happen? Is it a known bug?
I'm running:
-- Server version: 5.5.37-0ubuntu0.14.04.1
-- PHP Version: 5.5.9-1ubuntu4
The times are not actually being 'tampered with'.
MySQL interally stores TIMESTAMP columns converted to UTC time, then uses a mixture of system and session (client session) values to determine what to display to the user.
You can check both of these values running the following query yourself.
SELECT ##global.time_zone, ##session.time_zone;
So when your PHPMA script generates its dump, its specifying a session time_zone variable so when you run it MySQL will convert them all from that timezone back to UTC. When you then go to import that to another database, it will still convert them back to the UTC values you're expecting.
So to summarise if the values in the dump with SET time_zone = "+00:00"; are all "1 hour behind" the values you see when querying via PHPMyAdmin, this only appears this way because the connection via PHPMyAdmin will have it's timezone one hour ahead of UTC.
Related
I'm having issues with timezones with MYSQL. Right now, I'm dumping the data via mysqldump, as such:
mysqldump -uuser -ppass --tab c:/temp --skip-dump-date dbName
This works exactly as intended, with the data in the database matching the .txt files that are generated. The problem comes with importing the data. To get around some foreign key issues during the import phase, I'm using the following code:
SET FOREIGN_KEY_CHECKS = 0;
LOAD DATA LOCAL INFILE 'c:/temp/tableName.txt' INTO TABLE tableName;
SET FOREIGN_KEY_CHECKS = 1;
This also has no issues, except afterwards when I check the database, all the TIMESTAMPs are shifted by 5 hours forwards. I know this has to be a problem with time zones (I'm UTC-05:00, so the shift time makes sense), but I don't understand what should be done to stop the database from assuming that a shift in time needs to be done.
Along my searches for answers, I came across a similar SO problem, but the issue was backwards. Importing was fine, exporting was shifted.
MySQL data export changes times
Furthermore, I have seen some suggestions to look at this information in MYSQL, but I don't exactly know what I should do with this information now that I have it.
SELECT ##global.time_zone, ##session.time_zone;
Gives me:
SYSTEM +00:00
Is there a way to tell MYSQL to import without changing TIMESTAMPs? Should I change some sort of time zone setting? If so, should I change it for import, or export? I'm not planning on moving the database across any time zones.
UPDATE 1
In the mean time until I know best practice, I have tried the following change directly before using the block of LOAD DATA commands:
SET TIME_ZONE = '+00:00';
This has solved my problem (where I expect my dump to be the same as the files I used to create the database). Afterwards, I change the time back to -05:00, but I'm not sure if it was necessary.
Use the --tz-utc option to `mysqldump. From the documentatin:
This option enables TIMESTAMP columns to be dumped and reloaded between servers in different time zones. mysqldump sets its connection
time zone to UTC and adds SET TIME_ZONE='+00:00' to the dump file. Without this option, TIMESTAMP columns are dumped and reloaded in
the time zones local to the source and destination servers, which can cause the values to change if the servers are in different time
zones. --tz-utc also protects against changes due to daylight saving time. --tz-utc is enabled by default. To disable it, use
--skip-tz-utc.
I am exporting mysql table to setup it on live, but while exporting DB I noticed that my date column value is changing.. If it was "2007-06-11 00:00:00" earlier then after export it is now changed to "2007-06-10 18:30:00",
why this is so?
anybody have idea about this?
Bug #13052 existed in versions of MySQL prior to 5.0.15, in which dump files expressed TIMESTAMP columns in the server's timezone but did not include a SET TIME_ZONE command to ensure anyone (or any subsequent server) reading the dump file understood that; without such a command, receiving servers assume that any TIMESTAMP values are in its default timezone.
Therefore a transfer between servers in timezones offset by 18:30 (e.g. from South Australia to California) would lead to the behaviour you observe.
Solutions to this problem, in some vague order of preference, include:
Upgrade the version of mysqldump on the original server to 5.0.15 or later (will result in the dumpfile expressing all TIMESTAMP values in UTC, with a suitable SET TIME_ZONE statement at the start);
Prior to export (or import), change the global time_zone variable on the source (or destination) server, so that it matches the setting on the other server at the time of import (or export):
SET GLOBAL time_zone = 'America/Los_Angeles'; -- ('Australia/Adelaide')
UPDATE the data after the fact, applying MySQL's CONVERT_TZ() function:
UPDATE my_table
SET my_column = CONVERT_TZ(
my_column,
'America/Los_Angeles',
'Australia/Adelaide'
);
If using either solution 2 or solution 3, beware to use the exact timezone of the relevant server's time_zone variable, in such a manner as to include any daylight savings time. However, note that as documented under MySQL Server Time Zone Support: "Named time zones can be used only if the time zone information tables in the mysql database have been created and populated." The article goes on to explain how to create and populate the time zone information tables.
before export database just follow below steps:
export with custom option
uncheck the checkbox below
Dump TIMESTAMP columns in UTC (enables TIMESTAMP columns to be dumped and reloaded between servers in different time zones)
show in below image
I need to change the timezone of a single database is this possible?
I know we can change the timezone within our WHM (we are using a dedicated server from hostgator), however a large number of legacy software running on the server has a lot of +6 hours coding in it (i.e. server timezone is CST, we wanted the time in GMT so previous developers altered date/times manually within the code - bad!).
I am now working on a new software and would like to have it all in GMT, I know I can use date_default_timezone_set('GMT') however that will not solve MySQL inserts where the datetime column is set to CURRENT_TIMESTAMP as it will insert # CST timezone.
No, it's not possible to change the timezone for a single database within a MySQL instance.
We can retrieve the server and client time_zone settings with a query, like this:
SELECT ##global.time_zone, ##session.time_zone;
We can also change the client timezone for a session, or change the timezone for the entire MySQL instance.
But we need to be keenly aware of the implication that this change will have on existing client connections, and the how DATETIME and TIMESTAMP values already stored in the instance will be interpreted.
To have the server time_zone set at MySQL instance startup, we can modify the /etc/my.cnf file (or wherever the mysql instance initialization parameters are read from), under the [mysqld] section:
[mysqld]
default-time-zone='+00:00'
-- or --
It is also possible (less desirable) to add the --default_time_zone='+00:00' option to mysqld_safe
NOTE: Changing the timezone setting on the MySQL server does NOT change the values stored in existing DATETIME or TIMESTAMP columns, BUT since it does effectively change the context in which those stored values are interpreted, it will look like all of the values ARE shifted. (Where 08:00 was taken to mean 8AM CST, with the time_zone of the server changed from CST to GMT, that same '08:00' will now be taken to be 8AM GMT, which would effectively be 2AM CST.
Also keep in mind that TIMESTAMP columns are always stored in UTC, while DATETIME columns do not have a timezone.
http://dev.mysql.com/doc/refman/5.5/en/datetime.html
Each client session can change the timezone setting for their own session:
SET time_zone='-06:00';
But none of this really "solves" the timezone conversion problem, it just moves the conversion problem around.
There's nothing inherently "bad" with the application layer handling timezone conversions; sometimes, that's the best place to handle. It just has to be done correctly and consistently.
(What's odd about the setup you describe is that the app is storing DATETIME values as if the MySQL server time_zone is set to GMT, but the MySQL server time_zone is set to something else.)
If you can't change your current time zone you can change the result.
date 2015-01-05 12:06:16
Select date + Interval 2 Hour 'date' From ExampleTable
date 2015-01-05 14:06:16
You can modify the the default value instead of entering current_timestamp make it insert current_timestamp added to hours offset of your timezone. I just did it this way when didn't found any solution, had to invent my own.
So I have this app that receives packages from cell phones including gps time which is UTC. I store this in my mysql database from php currently.
I have two datetime fields one which contains the time from the phone and one which is the servers time.
my query looks like this: INSERT INTO GeoLocation(Time, ServerTime) VALUES(FROM_UNIXTIME(1353438497), UTC_TIMESTAMP())
I simplified and removed all other values. The current utc unix timestamp is right now: 1353438597 accordnign to http://www.unixtimestamp.com/index.php so my other cellphone timestamp is 100 seconds old, makes perfect sense.
now however to the funny thing. I should mention i live in Sweden with +1 timezone and the server is in sweden to, most likely configured to swedish time
when i use phpmyadmin to view the values just inserted it says that Time is 2012-11-20 20:08:17 but server time is 2012-11-20 19:08:23. So even tho both were correct utc times, one entered ass From_unixtime and the other with UTC_TIMESTAMP they now show different time.
I read you needed to set the timezone with SET time_zone = '+00:00';
so I tried to open a query window in phpmyadmin and entered
SET time_zone = '+00:00';
SELECT Time, ServerTime FROM `GeoLocation` WHERE 1;
but i still get the exact same times reported for both fields.
however phpmyadmin does run both rows because if i instead try this:
SELECT # #global.time_zone , # #session.time_zone
I get this:
##global.time_zone ##session.time_zone
SYSTEM SYSTEM
but if I do this:
SET time_zone = '+00:00';
SELECT ##global.time_zone, ##session.time_zone
I get this:
##global.time_zone ##session.time_zone
SYSTEM +00:00
So it doesn't make any sense to me, I have confirmed I feed it UTC time (from unix time) and yet it displays it as UTC+1 and it does not help to set time zone.
Any ideas?
The solution is to execute "SET time_zone = '+00:00';" before STORING data in the database (insert).
It will do you no good when you read the data, but if you call it when you store the data everything will be fine.
Currently whenever a user creates a new account, I have a Creation_date column that has datatype timestamp. Currently this timestamp reads 3 hours ahead of EST (if it's 5PM in Boston it reads 8PM). Is there a way to change the timezone to EST? What timezone is it set to currently?
This has to do with MySQL's timezone.
You can set it per connection (e.g. via PHPMyAdmin) with the following:
SET time_zone = timezone;
However, this will reset if MySQL restarts. So it is better set at the server level. Which, I assume, you can't.
I encourage you to read more from the MySQL Docs.
Accordingly with this question
SET SESSION time_zone = '+8:00'
TIMESTAMP values are converted to UTC when inserted into the DB and converted back to the current timezone set in MySQL on retrieval. The other answers show how to set the timezone in MySQL which will determine what value comes out of the database.
Another option is to use a DATETIME column, store ALL of your dates in UTC, and convert them to the desired timezone in your application (PHP or wherever you get the values from).
SET GLOBAL time_zone = timezone;
This is a COMPLETE example, for Argentina
SET GLOBAL time_zone = "-03:00";
you just need to change the "-03:00" for your timezone and run that command like a simple query, even in PhpMyAdmin.