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.
Related
I have a Django API application running on postgres with TIME_ZONE='America/New_York' and USE_TZ = True.
For a daily report, I need to query another database, MySQL, and compare records from the postgres DB to check for some updates. They should contain the same number of results. The MySQL DB's timezone is UTC however. How can I perform SELECT queries against the MySQL DB to have it match the same date range on my postgres DB?
Example:
These two queries should return the same number of results
# Django/Postgres with TIME_ZONE='America/New_York'`
MyObject.objects.filter(created_on__date=date(2016, 9, 17))
# External MySQL Databse in UTC
sql.execute('SELECT * from MY_TABLE where created_on BETWEEN "2016-09-17" AND "2016-09-18"')
What you need is to convert the date in MySQL to match America/New_York time zone.
The function to achieve that would be CONVERT_TZ() and since you need named time zone first you need to set up time zone tables.
If you are uncertain whether named time zones are available issue below query - if it returns zero the table is empty so using named time zones is unavailable and you need to populate them (I've mentioned a link to documentation above).
SELECT COUNT(*) FROM mysql.time_zone_name;
mysql_tzinfo_to_sql is used to populate time zones tables.
If your time zone is not a moving one then you can go with less safe, hardcored approach (not recommended) by explicitly typing the time difference like so:
mysql> SELECT CONVERT_TZ('2016-09-17 10:00:00','+00:00','+06:00');
-> '2016-09-17 16:00:00' -- Result
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.
I have a table with DATE column. All the dates are valid i.e. no 0000-00-00. But we were in fact using only the year part of these dates. I tried changing the type of this column to YEAR(4), I found following scenarios:
On my local system, MySQL version 5.5.37 via MySQL CLI, changing type retains the year.
On my local system, MySQL version 5.5.37 via Adminer, changing type retains the year.
Our internal DB server, MySQL version 5.0.46 via MySQL CLI, changing type retains the year.
Our internal DB server, MySQL version 5.0.46 via PhpMyAdmin, changing type retains the year.
Staging DB server, MySQL version 5.6.13 via PhpMyAdmin, dates in columns get converted to 0000.
Staging DB server, MySQL version 5.6.13 via MySQL CLI, dates in columns get converted to 0000.
What could cause these issues and how can I solve this? Currently we created a Rake task where we first create an additional column, copy existing column dates to new one, alter the column and copy just years back.
Edit: http://dev.mysql.com/doc/refman/5.6/en/upgrading-from-previous-series.html
Try this
ALTER TABLE `tablename`
CHANGE `columnName` `columnName` YEAR
This returns you 0000 in phpmyadmin. You should create a new column and rename it and then delete the old one.
The YEAR(2) data type has certain issues that you should consider before choosing to use it.
As of MySQL 5.6.6, YEAR(2) is deprecated.
YEAR(2) columns in existing tables are treated as before, but YEAR(2) in new or altered tables are converted to YEAR(4).
Read more here:
http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-13.html
I have two data environments 1) a data source 2) a production database powering a website. These two data environments are in two different timezones.
I am updating my production database incrementally by using
1. mysqldump - for syncing newly added records
2. sqlyog sja - for syncing updated records.
I have a column named modified_time (modified_time timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP) in each table to store the last modified time.
While syncing this data between two timezones I am not able to change the timezone.
I wanted to know how can I change the source timezone to target timezone while syncing
This is not possible at the db level and even if it were to be possible it would be inefficient, I would say deal with it in your application, its simple, all data is in a different timezone, so you just need to change it by a constant to get your time.
Again if the source data is using UTC (which is recommended) then you dont have any issue at all.
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