I've been working on MySQL recently, and I'm changing the default settings to my convenience. I change the locale from 'en_US' to 'es_PA' because this is where I live, and I want to check the time format that way.
The thing is that normally, every time I turn on my Rpi and enter the MySQL server, the locale is at 'en_US'. so I enter the super user and do this:
set global lc_time_names = 'es_PA';
So that changes everyone's locale. But whenever I disconnect from the server, and turn off the Rpi, the locale changes back to 'en_US'.
So, my questions are two:
Am I changing the locale right?
Is there a way i can change it by default on the my.cnf like I did with the UTF8 (character-set)?
Thanks.
You can specify all long options to MySQL as a .my.cnf setting. There is an --init-command option, which you can use to always execute when connecting. So, if you set the variable in that command, you're good to go.
Something like this should work:
[mysql]
init_command="SET lc_time_names='es_PA';"
Related
I want to know what is the time zone that is currently set in the MySQL server. I do not have administrator rights to the computer I am using so I've tried the method by checking the registry.
I am doing a table with a timestamp column and I noticed the time stamped is different than the one on my computer's time. Is there any reason for this? How do I check what timezone it is on the MySQL server? How do I change it to match my local/computer's time?
You can set the timezone (if you know your offset) for the session by using
set session time_zone = '+00:00';
and to revert to the system default
set session time_zone 'SYSTEM';
In an SQL timestamp column, SQL automatically converts the time to UTC before storing it, using the session's current time offset. It will be the machine's time offset unless you change it (3). Depending on your server's settings (sql.ini), it may or may not always concert back to the expect timezone. This probably explains the time discrepancy.
To get the current timezone offset, try executing
SELECT ##session.time_zone;
To manually override the SQL timezone for the rest of a particular session, execute the following, replacing 00:00 with your desired offset:
SET ##session.time_zone = "+00:00";
Have a look at the system_time_zone system variable.
This may help:
http://dev.mysql.com/doc/refman/5.5/en/time-zone-support.html
You can set the system time zone for MySQL Server at startup with the --timezone=timezone_name option to mysqld_safe. You can also set it by setting the TZ environment variable before you start mysqld. The permissible values for --timezone or TZ are system dependent. Consult your operating system documentation to see what values are acceptable.
You can convert a given timestamp to UTC (or any other TZ you want) with CONVERT_TZ
SELECT CONVERT_TZ(NOW(),##session.time_zone,'GMT');
Note that I use NOW() as simple demonstration, you would put in the timestamp you wanted to convert.
By the same token, you could convert a timestamp in your local TZ to the system
SELECT CONVERT_TZ($timestamp,'Your Time Zone' ##session.time_zone);
To check your shared server
<?php
echo date_default_timezone_get();
?>
To change
<?php
date_default_timezone_set("Africa/Addis_Ababa");
echo date_default_timezone_get();
?>
I'm using PDO prepared statements to insert data into a MySQL database, and I notice that apostrophes (single quotes) in strings are being stored in the database with back-slashes (\) preceding them.
I use stripslashes($string) on output, and of course this gets rid of them.
I searched my server's phpinfo() information (PHP version 5.2.17) for "magic_quotes" and found:
magic_quotes_gpc: local value = on, master value = on
magic_quotes_runtime: local value = off, master value = off
magic_quotes_sybase: local value = off, master value = off
Firstly, would turning magic_quotes_gpc off prevent the occurrence of the back-slashes? I don't currently have access to the server php.ini master settings, but as I understand it I would be able to disable it by configuring the root .htaccess file with the directive php_flag magic_quotes_gpc Off.
Secondly, is the prevention of these back-slashes in the database desirable? I ask this because I saw the somewhat cryptic remark here to "think twice before you do".
would turning magic_quotes_gpc off prevent the occurrence of the back-slashes?
Probably yes.
is the prevention of these back-slashes in the database desirable?
Yes. They serve no purpose. If you use PDO and properly parametrized queries, the problem that magic quotes used to address is already solved.
See the PHP manual on magic quotes on why they were used, and why they should no longer be used.
am trying to change the time of my sql server:
serve_time_zone=GMT Daylight Time
time_zone=SYSTEM
i have tried:
SET TIME_ZONE='+01:00';
to get the correct time_zone, but when i restart server to take effect it resets itself.
i have searched and not found anything which will not reset itself. I have now downloaded Hiedi SQL to view my database.
I want to advance the time of the database by 1 hour 1+GMT
Have you tried this: SET GLOBAL time_zone = timezone;??
I have a shared hosting mySql instance which has it's system_time_zone set to Pacific Standard Time and it's time_zone variable set to System, hence effectively it's running on Pacific Standard Time.
i.e. I've run the following command to find this out:
SELECT version( ) , ##time_zone , ##system_time_zone , NOW( ) , UTC_TIMESTAMP( )
I would like to change the default mySql database / local mySql DB time-zone to GMT/UTC time. I tried to run, SET time_zone = '+0:00', and this does execute successfully!
However, this does not seem to affect the time_zone variable, when I check the state of ##time_zone. I've looked at another post dealing with similar issue How to set MySQL to use GMT in Windows and Linux and I also checked the MySql documentation, with little progress. Since I am on a shared-hosting solution, I have limited access and I don't have access to more than what my PhPMyAdmin mySql functionality has on offer.
I wonder if there is any way to change the default_time-zone from within an SQL query, or do I need to fall back to the command line (to which I don't have access to, unfortunately).
Thanks for your help and advice,
Martin
In short, MySQL actually stores 'datetime' data type fields internally as UTC.
However, PhpMyAdmin shows you the dates using the server default time, hence your confusion.
For example, try adding this line before your SQL statement in PhpMyAdmin:
SET ##session.time_zone='+00:00';
SELECT * FROM MY_TABLE
See the MySQL documentation for further details, or the answer in this post: How to correctly set mysql timezone
Cheers
Matt
For shared hosting, you have to ask support-guys to help you and change default time zone for you? I had similar problem with Arcor hosting-provider, called them and they fixed it. Before that, I found temporary solution in date_default_timezone_set() from PHP code. Probably the best solution is to ask someone who has privilege to change that parameter.
<?php
date_default_timezone_set('UTC'); //define local time
$date=date('l jS \of F Y h:i:s A'); //type of time shown
$conn=mysql_connect("localhost","root","") or die('Could not connect!'); //your database connection here
$db_selected = mysql_select_db('databasename', $conn); //select db
$result=mysql_query("INSERT INTO table (date) VALUES ('$date')", $conn);
?>
Simply sent the time as VARCHAR into db hope it helps and sorry for syntax errors (if there are any).
I have an old application that started failing after an upgrade from MySQL 5.0 to 5.1.
A bit of research indicated this is due to "strict mode" which prevents inserting certain types of "invalid" values which previously were just automatically converted to something reasonable.
I tried SET ##SESSION.sql_mode = '' and SET ##GLOBAL.sql_mode = '' but I still get the error.
Also tried commenting out sql_mode in the my.ini.
Is there a stronger, sort of "nuclear" option to fix this?
In my application I usually make sure that the MySQL connection is using traditional mode by issuing
SET SESSION sql_mode = 'ANSI_QUOTES,TRADITIONAL'
on each new connection. I presume that if you just issue
SET SESSION sql_mode = ''
on each new connection, you will have solved the problem.
You should be able to change the default SQL mode for new connections by issuing
SET GLOBAL sql_mode = ''
but you must use an account with sufficient privileges to do this or it won't work.
I think that if you want to make sure a particular SQL mode is in operation for your application, the most robust way to do so is to set it for each and every new connection.
To allow invalid dates, you need:
SET sql_mode = 'ALLOW_INVALID_DATES';
But you'd better fix your application.