I have the offset in seconds to UTC, all timestamps stored on the database are in UTC, how to apply the offset during selection queries,
mysql_query("SELECT * FROM table WHERE unix_timestamp=unix_timestamp with offset applied");
mysql_query("INSERT INTO table (unix_timestamp) VALUES(UNIX_TIMESTAMP())");
I'd want to insert in UTC time to the database and retrieve in local time.
On PHP:
date_default_timezone_set('UTC');
$user_timezone_offset=-7200; // -2
Could I substract on select's runtime of mysql to the unix_timestamp field $user_timezone_offset and that would be it?
I am inserting in UTC which is what I need apparently, but for selection in user's local time I'd need to apply the offset to the timestamp stored in the database somehow.
Edit: I just came across this:
$user_timezone_offset="-2:00";
FROM_UNIXTIME(CONVERT_TZ(unix_timestamp,'+00:00','$user_timezone_offset'))
Would need to know how to apply it to a select query making the selection of unix_timestamp converted for comparison inside the select and the result also becoming modified for php's fetch_array
This seems to be the solution:
SELECT *, Unix_Timestamp(CONVERT_TZ(FROM_UNIXTIME(unix_timestamp), '+00:00', '$user_timezone_offset')) as unix_timestamp
Actually this has a problem - although on
mysql_fetch_array($result){ $row['unix_timestamp']; }
comes converted while checking on
WHERE unix_timestamp=value //assuming unix_timestamp
to be converted on the select - in there it is not converted and another
Unix_Timestamp(CONVERT_TZ(FROM_UNIXTIME(unix_timestamp), '+00:00', '$user_timezone_offset'))
has to be called for unix_timestamp to be "converted" each time a check is to be made against the converted value.
I think you may be overcomplicating the issue.
Timestamps are always UTC. When you retrieve a timestamp in PHP, it is in UTC.
When you convert a timezone using the date() function for example, it displays in whatever timezone the php.ini setting date.timezone is set to.
Therefore, if you have users with specific timezones, just call date_default_timezone_set() with the appropriate timezone prior to displaying dates in local time.
If you use the DateTime class, then you can specify the desired timezone when you construct the object.
Unless you have a very specific reason, there should be no need to perform timezone conversions when you fetch timestamps from the database. PHP handles this all for you.
Related
I work on an existing project that stores dates to a MySQL DB. The dates are stored as UTC since all users so far were in GTM+0 and no conversion was needed.
I now need to modify the code so that users from other time zones can use the system. The users choose their timezone when they register to the system, so I have a table holding the timezone for each user.
I know I can use CONVERT_TZ() when I extract and store the dates, but to do so means to go through all the queries and add this function.
When I do:
SET ##session.time_zone:='+7:00';
select now();
The result changes with the timezone variable.
When I do:
SET ##session.time_zone:='+7:00';
select myDate from myTable;
The result stays the same, returning what is stored in the DB.
Is there any way I can change the connection string or is there a session variable I can use that will affect the queries without having to add CONVERT_TZ to every single query?
Edit: this is not a duplicate of Should I use field 'datetime' or 'timestamp'? since using timestamp means I need to change all the date field in the DB, while I try to change something more global so I will not have to do massive changes the Db fields or the code.
I'm working on a shared hosting so I don't have access to mysql configuration files.
The default timezone on that system is 'America/New_York' but I need to use UTC -5:00 for my databases.
Everytime I perform a query the timezone is set to UTC -5:00 like this:
SET time_zone='-5:00';
If I want the current time, SELECT NOW() returns the correct time and date, but when updating a table mysql uses the SYSTEM time and not the set timezone
UPDATE administradores SET ultimo_acceso=NOW() WHERE id=1
Why does those values are different? Shouldn't be the same time in both queries since I'm overriding the timezone?
I also tried with INSERT statement and that works fine.
If the ultimo_acceso field is of type TIMESTAMP, then the value is actually being stored as UTC and then converted back to the current time zone when you select the value back out. So you need to set the time zone again in the select statement.
If you are using a DATETIME data type, then the value you set should be persisted without conversion and you will get back exactly what you store - regardless of the timezone setting at time of select.
See the MySQL docs on this subject.
Note that DATETIME, DATE, and TIME fields will always return the exact time you placed into them, regardless of the value of the time_zone variable.
TIMESTAMP fields will automatically convert their values to the timezone specified by the time_zone variable.
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);
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.