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
Related
I have a Perl Catalyst app that store some times in a MySQL database. The times are of type TIMESTAMP and initialized with NOW().
When reading back the times they appear to be in the databases default time zone. However when using the mysql shell I can easily set the time zone by SET time_zone = '+03:00'; and get the correct local time for my time zone.
Is there a way to set the time one like this in Catalyst or DBIx at run time?
I want to be able to support different time zones, for different users, so just changing the default time zone for the database is not enough. I am also aware that I can format the time in Perl after I get the data from MySQL, but there is so much automation going on with Catalyst, DBIx and Template Toolkit so getting the data correctly from the database to start with would be so much more convenient.
My general advise is to set the datetime in your application, not rely on the datetime of the database server. If you don't need to know which timezone a datetime had when it was set you should store it in UTC. If you need to know the timezone later you need to use a database datatype which supports this like 'timestamp with timezone' in Oracle.
See my answer for Formatting timestamp field for output in TemplateToolkit which seems to be what you're asking.
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'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.
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.
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