I've build a web app which is currently being used by a number of customers.
In v1.0 it didn't support time zones and stored all datetimes in Europe/Amsterdam.
Now in v1.2 it stores all datetimes in UTC and shows the right date in the web app according to the user's selected time zone.
Now I want to provide a mysql query to my customers (who are updating and already have some data) to update all datetime fields to UTC in phpmyadmin.
I'm using CakePHP so all created/modified fields need to be updated.
Can anyone show me what this query looks like?
You can use the timezone conversion features provided by MySQL itself:
-- "table" and "field" are obviously placeholders
UPDATE table SET field = CONVERT_TZ(field, 'Europe/Amsterdam', 'UTC');
Be sure to make a backup first.
Note that CONVERT_TZ requires MySQL to be aware of the timezones. You can import them to the database with a simple shell command (requires root access to the DB):
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p -D mysql
This can be done multiple times, so it doesn't hurt to execute it if you don't know if the timezones have already been imported. You can usually ignore warnings concerning some obscure timezones.
Related
I'm building a application that needs to store Timezones.
Rather than building my own table of timezones would it be copacetic to use mysql's already there table (mysql.time_zone_names)?
If I use a Time_zone_id of '94' and mysql updates its timezone tables, will 94 still be America/Chicago?
MySQL loads its timezone tables from your OS's /usr/share/lib/zoneinfo when you run mysql_tzinfo_to_sql. Then it keeps the data in the mysql database.
So the entries are only as stable as that file. If the OS adds or removes time zones in zoneinfo, and you reinstall your MySQL instance and run mysql_tzinfo_to_sql again to load the changed time zones, then the numeric time_zone_id values in MySQL could change.
I would recommend using the timezone name, not the numeric id.
After inserted record into database, created_at timestamp not display right time, it late 2h from server.... Also If i type into mysql SELECT NOW() it show right time, any idea what is problem?
Edit..
It take date from Carbon class... any idea how to change it?
The default timezone for laravel is UTC which is located in config/app.php file.
If you want to change the timezone to your preferred timezone, choose your preferred timezone from this list or from this list and replace the UTC with your chosen timezone.
A few notes. As per the comments here, to be precise, the last 3 comments: You should not change the default values.
Storing dates of different timezones in data source of a same
application (by changing the timezone in config for current user &
letting Laravel handle it from there on) is just asking for trouble &
is a bad design. You will lose data integrity. What will happen when a
user changes timezone? You'll update all the dates in the database for
that user?
Store dates for all users as UTC (or any other timezone of your
choosing, just select one & stick to it). Laravel already uses the
excellent Carbon library, use it to convert dates from your
timezone (in which they're stored in DB) to users' timezone (which
you would store with in every user's settings) when you display the
dates.
For the other people that also still have the wrong date/time after changing the config file:
My problem was in php in my vagrant box (Homestead).
To solve it I did:
First ssh into you vagrant box and then run this in the command line:
date
This should return something like "Mon Jul 3 13:48:52 CEST 2017". Check if this date/time is correct. If not do the following:
sudo ntpdate -b pool.ntp.org
This should update your system time. Check it again with the first command. If it is still not write you probably have to change your systems timezone. You can do this by running:
sudo rm -f /etc/localtime
sudo ln -sf /usr/share/zoneinfo/Europe/Amsterdam /etc/localtime
You can use any timezone you wish, I prefer "Europe/Amsterdam".
You can get other timezones here
I am working on a database which contains a number of "Date" fields. These dates need to be converted to UTC for some output, which I intend to do using
CONVERT_TZ('theField','GMT','UTC').
However, the ##global.time_zone variable is not currently set (returns "SYSTEM" at present), and the timezone information table is currently empty. I believe this needs to be filled by running the mysql_tzinfo_to_sql shell script (http://dev.mysql.com/doc/refman/4.1/en/time-zone-support.html).
My problem is that I don't have any kind of shell access to the system in question, so it's impossible for me to run the mysql_tzinfo_to_sql script. So I therefore have two questions...
1) If MySQL is using the "SYSTEM" time zone at the moment, is there any way to determine exactly what the system time zone is (remembering I don't have shell or any other access)?
2) Is it possible to generate the information in the MySQL time zone table by some means other than the shell script, i.e. entirely within MySQL itself?
Grateful for any suggestions, thanks.
You can check what time zone you are using with:
SELECT ##global.time_zone, ##session.time_zone;
Setting the timezone:
SET ##global.time_zone = 'SYSTEM';
If you want to know the time zone of the system:
Windows:
Go to cmd and key in systeminfo
Linux:
date +%Z
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 have a forum where users can post comments. When a comment is created its corresponding datetime value is stored in UTC format.
I intend to present the data in local time, say 'ASIA/SINGAPORE';
2 options:
use convert_tz each time querying the database. I dont like the
approach, cause it makes me rewrite the select_expr each time querying.
use SET time_zone = 'ASIA/SINGAPORE';
As for the second option, I want to know what is the validity scope of the command (no super privilege here). more specifically, say if i'm using a php application, does the config gets invalid as i close db connection? should i issue the command each time querying the db?
Tnx.
MySQL variables are scoped in the connection (lowest level, between libmysql <-> mysqld). It means, that if PHP itself or some application library uses any kind of mysql connection pooling, then you could observe this variable disappearing (because of invisible connection switching), and the variable definitely will disappear after disconnecting.
If you are not happy rewriting your query, you probably could select apropriate tz name on the fly -- say, form a users table, as long as you have the id of the logged user, like this:
SELECT convert_tz( ..., ..., (select user_tz from users where user_id = ...))