I run the following MySQL query:
select unix_timestamp('2011-03-13 02:00:13'), unix_timestamp('2011-03-13 02:20:41'), unix_timestamp('2011-03-13 02:40:10');
And get the following odd result:
1300003200, 1300003200, 1300003200
I think there's some kind of daylight savings time going on here, though it still seems odd that all the values are magically the same.
I'd appreciate suggestions of how to prevent MySQL from doing daylight savings time things here, as well as some explanation as to why all the results are the same.
MySQL's behavior is correct, if your server's time zone "CDT" observes DST and you haven't set your session time zone to something different.
The UNIX_TIMESTAMP() function uses your session's time zone to interepret the value you give it.
The server interprets date as a value in the current time zone and converts it to an internal value in UTC.
...
Note: If you use UNIX_TIMESTAMP() and FROM_UNIXTIME() to convert between TIMESTAMP values and Unix timestamp values, the conversion is lossy because the mapping is not one-to-one in both directions. For example, due to conventions for local time zone changes, it is possible for two UNIX_TIMESTAMP() to map two TIMESTAMP values to the same Unix timestamp value. FROM_UNIXTIME() will map that value back to only one of the original TIMESTAMP values.
— http://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_unix-timestamp
The timestamps in question did not exist in your time zone, so the server is giving you the most accurate possible answer... it's the time in UTC that the clock moved forward to, when the time moved forward, less than an hour prior to your datetime literals, which represent "times that never existed on that day" in your time zone.
If those timestamps are intended to be times in your local time zone, then the answer is that those are invalid values, since that time never happened where you are. On the other hand, if those timestamps are actually assumed to already be in UTC, then you're not getting the correct answer from UNIX_TIMESTAMP() on any query, because the time is being converted "from" a time zone it isn't actually expressed in.
If you SET ##TIME_ZONE = 'UTC'; and repeat the queries, you'll see what I mean, since UTC has no DST. This statment only sets your session's time zone, not the whole server.
If running SET ##TIME_ZONE = 'UTC'; gives you an error message such as ERROR 1298 (HY000): Unknown or incorrect time zone: 'UTC', it is likely that you have not populated MySQL with timezone information. As described here you can load this information by using the command:
mysql_tzinfo_to_sql /usr/share/zoneinfo/ | mysql -u root mysql -p
where the path /usr/share/zoneinfo may need to be replaced with a path specific to your system.
Related
I am running MYSQL 4.1 database that stores call center data for our offices that operate in Europe.
My MYSQL database sits on a Windows 2003 server that's has its time zone set to Central European Time, which automatically adjusts to day light savings.
I want to able to produce a report that shows the log date and time in the correct time zone to our customers in Europe.
My database stores the log date / time of the call as a unix time stamp. So therefore the dates stored as UTC. I found MYSQL function that can easily adjust the log date time to a time zone of your choice.
It's called CONVERT_TZ. (More info:http://dev.mysql.com/doc/refman/5.1/en/date-and-time-functions.html#function_convert-tz)
Example: SELECT CONVERT_TZ('2004-01-01 12:00:00','UTC','CET');
I tried to apply this to call that was logged on 01-06-2013 22:12
CONVERT_TZ(FROM_UNIXTIME(o.logdatex), 'UTC','CET') 'CET_L_DATETIME'
(logdatex is the unxtimestamp for when the call was logged)
To my confusion the statement returned - 2013-06-02 00:12:56.
I wanted to see what was returned when I just selected FROM_UNIXTIME(o.logdatex)
It returned the correct time! 2013-06-01 22:12:56 (This call was logged from our Amsterdam office)
My question is, does the FROM_UNIXTIME function automatically adjust the time from UTC according to what the time zone MYSQL server is set to? I cannot find any documentation that says it does.
My assumption this is because when you do FROM_UNIXTIME(o.logdatex) you convert from UTC to timezone of your server.
And now you date is not in UTC timezone. So in CONVERT_TZ(FROM_UNIXTIME(o.logdatex), 'UTC','CET') you don't convert from 'UTC' but from timezone of your server so you get a strange result for you.
Try to select FROM_UNIXTIME(o.logdatex) as a separate field in your query and compare results.
I want to migrate our mysql server from shared hosting to local server.
Current server is in MST time zone and the values for the CURRENT_TIMESTAMP in databsse is stored as -7:00 GMT.
Now I want to move complete application on dedicated server in India. Also want to convert the date values stored in -7:00 GMT to +5:30 GMT.
I can accomplish this task of updating the dates by writing script to update the time, however I would like to know if is there any way I can do this from database itself (at time of import or while exporting itself)
mysql version 5.0.96-log. I am not getting option export timestamp in UTC.
When using mysqldump, set the flag: --tz-utc to force all timestamps to be exported as UTC. ( http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html#option_mysqldump_tz-utc ). Note here --tz-utc is enabled by default. So you should have to do nothing: but test first :)
If just working with timestamps on the server you don't have to do anything to convert them, from the documentation on TIMESTAMP post MySQL 4.1 ( http://dev.mysql.com/doc/refman/4.1/en/timestamp.html ):
"values still are stored in UTC, but are converted from the current
time zone for storage, and converted back to the current time zone for
retrieval. As long as the time zone setting remains constant, you
get back the same value you store. If you store a TIMESTAMP value, and
then change the time zone and retrieve the value, the retrieved value
is different from the value you stored."
This is easy to test:
Save a timestamp to your table
Change the server's timezone
Retrieve it: the return value should reflect the new timezone.
So another option is you could just have both the servers set to the same timezone while doing the export / import, than set them back to the correct timezone(s) after it is complete, but note with MySQLDump this should not be necessary.
General syntax
SELECT DATE_ADD(<column_name>, INTERVAL HOUR);
for changing to UTC to MST
SELECT DATE_ADD(NOW(), INTERVAL 7 HOUR);
Is there is any possibility in database, What ever time i am given which should store as GMT time stamp. If it so, Please share me.
For PostgreSQL, your table should have a column of type timestamp with time zone (timestamptz for short) like this:
CREATE TABLE tbl (id serial, ts timestamptz);
If what you want to store (let's call it my_ts) is ...
a local timestamp without time zone, i.e. it agrees with the current setting of timezone in your client:
Insert as is, everything is saved as UTC automatically internally:
INSERT INTO tbl (ts) VALUES my_ts'
a timestamp with time zone:
Insert as is, everything is saved as UTC automatically internally:
INSERT INTO tbl (ts) VALUES my_ts;
a timestamp without time zone but from another time zone:
Say, you get timestamp without time zone values from the Olympic Games in London, but your client thinks you are at a different time zone. Transform the timestamp with the AT TIME ZONE construct:
INSERT INTO tbl (ts) VALUES my_ts AT TIME ZONE 'Europe/London';
If you use the time zone name (instead of a time zone abbreviation, BST in this case), DST (daylight saving time) rules are applied automatically. Details in this related question.
More about timestamp handling in PostgreSQL in this related answer.
Now, if you want to display tbl.ts as UTC (~ GMT) timestamp without time zone, regardless of your current time zone, retrieve the values like this:
SELECT ts AT TIME ZONE 'UTC' FROM tbl;
Note that AT TIME ZONE has a different effect when applied to timestamptz than with timestamp! Read the manual carefully.
http://dev.mysql.com/doc/refman/5.5/en/datetime.html
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.) By default,
the current time zone for each connection is the server's time.
Times in timestamp with time zone (and the old-style timestamp, but you shouldn't generally use that) are always stored in UTC ("GMT") in PostgreSQL. They're converted to and from UTC for display. If you want them to be treated as UTC for input and output:
SET timezone = 'UTC'
in each session, or set the param at the database or user level. Your app must then send all timestamps qualified with a time zone if they're in a TZ other than UTC; you've told the system that "local time" is UTC.
The AT TIME ZONE construct can be useful if you want to explicitly convert timestamps to a time zone other than the default, eg:
regress=# SELECT TIMESTAMP '2012-01-01 00:00:00 UTC' AT TIME ZONE '+08:00';
timezone
------------------------
2012-01-01 16:00:00+08
(1 row)
The keyword you are looking for is UTC instead of GMT ("For most common purposes, UTC is synonymous with GMT, but GMT is no longer precisely defined by the scientific community.", wikipedia).
For MySQL, you can use the CONVERT_TZ() function (please note the warning in the manual about named time zones, it can break your queries if it's not properly set up).
Just a word of caution: there is no 100% reliable way to work with timezone conversion between MySQL and your application (see my blog post about mysql time zone conversions to learn in detail about why this is). It's better to pass your datetime strings to MySQL in UTC directly (e.g. by doing the conversion in the application itself). You almost always end up storing datetimes in a DATETIME field using UTC formatted date strings if you need reliability.
According to mysqltutorial
The values of the MySQL TIMESTAMP columns depend on connection’s time
zone. When insert values for MySQL TIMESTAMP columns, they are
converted to Universal Coordinated Time (UTC) from connection’s time
zone. When you select the value, the server converts it back from UTC
to the connection’s time zone so you have the same value that you
inserted.
Where does it get this info. from, the time the user sets his OS to or from some other method?
Javascript also has a way to do timezones but is more involved: onlineaspect
To specify connection-specific time you need to perform
SET time_zone = TZ;
Where TZ can be either numerical offset like +11:00 or name of timezone Asia/Vladivostok (for the latter you need to import timezones description. Ask your DBA to do so)
the example there is wrong, i just tested it. it returns the previously inserted timestamp, regardless of the timezone. mysql will always insert the time you specify, without modifying it. if you need timezone adjustment, you have to tell mysql explicit to do so; otherwise all times are assumed to be "local server time".
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.