Need some ideas on how to convert an entire database TIMESTAMP columns from one timezone to another.
The current server is UTC, MySQL is also UTC so everything is good in that area. All time related columns are TIMESTAMPs. The problem is that when the time information was being entered, they were in EST/EDT. For example, enter start time: data is 1/1/2011 08:00:00 AM (EST/EDT). Because timezone wasn't implemented at the start, the database stored this as 08:00:00 UTC. So all the data in the database is stored like this. Once we get data that requires timezone info, this model will break.
The question is: how do you convert all these TIMESTAMP columns into the correct UTC time? The code will be changed to deal with this on the display side on a go-forward basis but what about historic data?
The simplest way seems to do a mysqldump --tz-utc of some sort and then import the data back, then release the code. However, I can't seem to find a good example of how to do this properly or if there are other ways to do this in the most efficient way possible.
Thanks!
Could you use the MySQL AddTime function to update the existing data?
UPDATE MyTable SET MyTimeColumn = ADDTIME (MyTimeColumn, -8:00:00) WHERE <the data is bad>
Related
First, Thankyou for sparing your precious time to look upon my beginer question
So the thing is, I still can't fathom how datetime work on MySQL
"Can I, upon changing timezone, convert all datetime columns in all tables to match the new timezon?"
For example, my server local time is UTC +7
I have database with several tables which some contain column with datetime data type (eg. CreationTime, updatedTime, visitTime, etc)
Now supposed to, somehow, I plan to move my server to a different timezone, let say UTC +8.
Can I do one method to convert all the datetime columns in many tables automatically to the new timezone?
let say the old datetime is 22/2/20 18:00:00, after the conversion, become 22/2/20 19:00:00. All with a method or functions (preverabli native to mysql, but i can compromised using php), considering that manually writing a list of all tables or all columns name one by one is impossible?
Sorry if the question is superficial. I have exploring the web, and stackoverlow, but my meager knowledge in programming just can't graps most of the discussion.
Thank you very much.
The same question was here: Should MySQL have its timezone set to UTC?
Based on these answers you can change /etc/mysql/my.cnf file to change default database timezone:
default_time_zone='+00:00'
or
timezone='UTC'
Notice: The right way is to save all timestamp data in UTC+0 format (backend), and then fetch it with actual client timezone (frontend).
I am using DATETIME field to store my dates in MySQL. Without any timezone specified directly (there is just a datetime column)
But when timezone was changed on server MySQL updated all datetime columns according to new timezone.
Actually switching to EDT was the reason.
I don't need to recalculate my dates automatically - just want to store specific dates in it.
So even if tz changed manually to UTC from EST date should be same (from characters POV) if it was 2016-01-01 18:55 it should be same in any new tz..
I did not run any scripts\queries to update dates.
So it was performed either by MySQL itself or by server.
Need advice what I need to check to find and disable such feature.
Make sure you are using DATETIME and not TIMESTAMP
[From the MySQL documentation][1]:
MySQL converts TIMESTAMP values 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.)
You should also review this post (Duplicate):
Will changing a MySQL timezone change values of DateTime fields in a database?
I am sorry for the mess I brought
Just extended my query to grab some old dates - and it looks unchanged
So error defenetly in my code..
Anyway - thanks for your help
Is there MySQL equivalent to Oracle's TIMESTAMP WITH TIME ZONE?
I need to map a Oracle table, which has some columns with that datatype, into a MySQL table but I can't seem to find an easy way to do this without resorting to some MySQL functions.
Thanks and best regards.
No, you'll need to split the data into 2 columns, one a datetime, and the other holding the timezone information. But what you put in the latter field is dependant on what you've got stored in Oracle - the TIMESTAMP WITH TIME ZONE Datatype can contain the TZ offset and (optionally) the time zone region. Obviously the latter is a requirement for the date time to be semantically correct, but IIRC Oracle does not enforce this data being populated.
without resorting to some MySQL functions
Since MySQL doesn't have the datatype, it'll be very difficult to write MySQL function to process it - it's a lot simpler to create a MySQL compatible representation in Oracle where the datatype is supported. You just need to work out what data you've actually got and decide how you want to represent it in MySQL. By convention that means storing it in UTC along with the TZ in a seperate column, then convert it on selection with the convert_tz function (always from UTC)
MySQL always store timestamps as utc. Dates are always stored without timezone information.
You can configure mysql to return values from now() in different timezones.
To store the current offset you need to add this to some column on your own.
I am having this trouble in converting the exiting time string into a new Time object.
When I type this in console
t = Time.parse("8am")
2010-12-06 08:00:00 +0530
it gives back 08:00 as result as seen above.
But when I store this value using
business.start_time = t
business.save(:validate => false)
it stores 02:30 in MySql db.
This happens only when I store via console. When the same data comes from forms, it stores correctly as 08:00 in MySQL table. Is there any problem here. The time zone is set different from the default utc. Please help. what should i do.
I have to parse through all the records in a table and take one string attribute and convert it into its equivalent Time class value and store it in another attribute in the same table. I am writing a rake task for it. But while storing, I get 02:30 instead 08:00 (for example).
Be very careful with dates and MySQL. Datetime fields are stored as if they were strings in the db--so whatever Rails is sending in (check your log for the SQL) is what will be stored. I assume you're set to UTC in your environment.rb, so your Time object is being output in UTC as a string.
MySQL is poor (in my opinion) with respect to handling times in different zones and converting between zones.
I recommend you don't rush through your date handling. Always handle dates in your application and DB in UTC, and do any conversion to a specific timezone on a parsing (by specifying the timezone) or by formatting it in the view.
The time seems to be stored in UTC. Try setting the timezone correctly when starting your console session.
Say I have multiple servers in multiple locations and I want to use MySQL's datetime type for the field date and I always want to have the field date have the UTC timestamp so I would execute a UTC_TIMESTAMP() when I add it to the database. Now say I want to have MySQL output the UNIX TIMESTAMP for it.
When I do this on Server A I get the string "2009-06-17 12:00:00" doing the UNIX_TIMESTAMP(STRING) on it gives me the number 1245240000 back. Which is 2009-06-17 12:00:00 in UTC time. Now I do the same thing on Server B.
I get the same string back since its the UTC string but when executing UNIX_TIMESTAMP(STRING) again I get back the wrong number back 1245232800 which is the UTC +2 time. How do I get around this? Should I do the convertion from string to timestamp on the PHP side?
G'day,
I'll ask the obvious here, did you check the date and time on both machines?
Edit: ... and the MySQL timezone was the same on both machines?
Update: Ok. The problem is in the fact that the timestamp string being passed into UNIX_TIMESTAMP is interpreted to be a value in the current timezone which is then converted back to UTC so, because you're in MEZ, two hours is subtracted to return it back to UTC so 7200 is subtracted from your timestamp when it is converted back to a Unix timestring.
Hence, the variation you see when using UNIX_TIMESTAMP() to convert is back to a Unix Epoch timestring.
BTW Shouldn't you be using a TIMESTAMP type for storing off your UTC_TIMESTAMPs instead of DATETIME type?
Update: Decoupling presentation time from stored time is definitely the way to go. You can then reuse the same data all around the world and only have to convert to and from local time when you are presenting the data to a user.
If you don't do this then you are going to have to store off the timezone when the timestamp was made and then go into all sorts of complicated permutations of having to work out if
the local timezone was in daylight saving time when it was stored,
what the difference is between the timezone at the time that the data was stored and the timezone where the data is to be presented.
Leaving it all storeed as UTC gets rid of that.
Most users won't be that happy if they have to work out the local time themselves based on the UTC time returned so systems usually convert to current local time for the user.
This is of course if the user wants the data expressed in local time which is usually the case. The only widely used system I can think of, off the top of my head, that stores and presents its data in UTC is system for air traffic control and flight plan management which are always kept in UTC (or ZULU time to be more precise).
HTH
cheers,
Have you tried doing this?
Execute this instructions together.
SET time_zone = 'UTC';
SELECT FROM_UNIXTIME(0), UNIX_TIMESTAMP('2009-06-17 12:00:00');
// 1970-01-01 00:00:00 1245240000
They only affect the client session, not the server configuration.