PHP & MySQL Timezone - php

My hosting environment (PHP & MySQL) is on GoDaddy, and their timezones are by default America/Denver for both PHP & MySQL.
I currently have a website, and the PHP scripts have
//Set timezone
date_default_timezone_set('Europe/London');
On all scripts. (It's in a config file that is always included)
I believe that settings my PHP to date_default_timezone_set('Europe/London'); is the correct thing to do for UK users.
However, I'm coming unstuck with regards to MySQL.
Sometimes, one of my PHP scripts Will store a date/time in MySQL Server and expressively tell MySQL what the timestamp is
PHP -> Store "2020-01-01 15:00:00" -> DB
If I open phpMyAdmin and view the stored information, I can see that 2020-01-01 15:00:00 is stored.
Although now, I believe that that's actually 2020-01-01 15:00:00 in America/Denver time - is my thinking on this correct?
Other times, I use to have a MySQL field with a DEFAULT value of CURRENT_TIMESTAMP.
I let MySQL Generate the current TIMESTAMP for an insert when i want it to be the current time, however, what I expected to be saved in the UK format, is in American/Denver time - So I may run an insert at "2020-01-01 13:00:00" in the UK, but in MySQL, the result stores are "2020-01-01 06:00:00" (Because MySQL Generated the timestamp, not PHP)
My questions are, Am I right in thinking that to fix this little mess; I need to:
1: Update all historic PHP generated timestamps that are currently stored and rewind them 7 hours, so they are in the server's timezone
2: When connecting to MySQL with PHP, run this query: SET time_zone = 'Europe/London'; then run any and all further queries, SELECTS, INSERTS, etc
-this will then show me the UK version of the stored timestamps if I select them
-this will automatically wind any new PHP generated timestamps back to the MySQL server timezone when inserted

Related

SQL Time Zone Issue

I am working on a project based on PHP i have an issue that i purchased a hosting whose server is of another country and i am in Pakistan when i enter data in database table from PHPMyAdmin in enters the date of that country which is 11 hours behind us that's why my insert queries and update queries not working Php time zone is set but server time zone is not set.
php_value date.timezone 'Asia/Karachi';
i use this is my htaccess file Also use
date.timezone = "Asia/Karachi"
in php ini file
(To long for comment)
If you write a website with user specific timezones, then managing timezones at database site is a bit complicated. I prefer this solution:
Try to store all timestamp as bigint values in unix time.
Converting time to string only at user interface.
Examples
For Database storing I use:
UPDATE table SET start_time = UNIX_TIMESTAMP();
Results are either retrieved as native integers or converted to UTC/GMT time:
SELECT unix_time, UNIX_TIMESTAMP(db_date)
You can test it with:
SELECT UNIX_TIMESTAMP(), UNIX_TIMESTAMP(now());
In PHP, you can now simply do fast time calculations by adding and substracting. It printing a time at the user interface, set the timezone (maybe evaluated by a database query) and use date() or strftime(), or any date+time class.
You should set your MySQL timezone when you open the connexion to the database server in PHP.
You can see some example here: Set timezone in PHP and MySQL
You could also do it like this (works with MariaDB, never tested on MySQL):
$db->exec("SET time_zone='Asia/Karachi';");
That way you don't have to update your database configuration and you can update the set depending on a variable.

Wrong date display when using "date" data type in postgres

Some tables use the "date" datatype. In the old system (psql 9.1/PHP5.3), when the date is stored in the database, it is stored correctly. However, in the new system (psql 9.6/PHP 7.1), the date stored incorrectly. For example, when storing 7/13/10 in the old system, it stores the following:
stage_date | to_timestamp
------------+------------------------
1279004400 | 2010-07-13 00:00:00-07
When storing the same date in the new system, it stores the following:
stage_date | to_timestamp
------------+------------------------
1278979200 | 2010-07-12 17:00:00-07
Both Operating systems are set to "America/Los_Angeles". The old database is set to use "localtime" (which in 9.1 would use system timezone). The new database uses "PDT".
What would cause the value in the old system to be set to "1279004400" vs "1278979200" in the new system?
Part of the table definition:
Column | Type
--------------+---------------------
id | integer
stage_date | date
In case anyone else ends up here: The table view was using the extract function to convert the date to an epoch. The behavior of extract changed in PostgreSQL version 9.2.
This change reverts an ill-considered change made in release 7.3.
Measuring from UTC midnight was inconsistent because it made the
result dependent on the timezone setting, which computations for
timestamp without time zone should not be. The previous behavior
remains available by casting the input value to timestamp with time
zone.
Please see the answer to the following question for more details:
Different results for extract epoch on different PostgreSQL servers

Dates returned from MySQL timestamp column change times

I'm currently working on an issue where the PHP server is located in Europe but the database server is located in Mexico.
In my app, the timezone is set with:
date_default_timezone_set('America/Mexico_City');
The application doesn't set the MySQL timezone, so it appears to use the system timezone, which is America/Mexico_City.
The strange thing is when I query a timezone column in MySQL, it sometimes gives me dates using the time in Mexio and sometimes with the time in Europe.
I know that mysql stores timestamps as an integer and returns them as a date string, and I could probably solve this by explicitly setting the timezone the database connection is using to Mexico with $db->query("SET time_zone = 'America/Mexico_City'");
But my question is, why would it sometimes return the timestamps as date strings with Europe times and sometimes with date strings in Mexico times? The application doesn't use any type of specific caching.
Probably, your problem is related to this questions.
Having Timezone problems with PHP and MySQL
and
How do I set the time zone of MySQL?
Note how they use either SET GLOBAL time_zone = "your_time_zone" or SET SESSION time_zone = "your_time_zone"
Hope it helps :)

MySQL and PHP TimeZone

In my PHP.ini file I set the TimeZone like so...
'America/New_York'
so when i ran a simple php Date() function
echo date("Y-m-d H:i:s");
I get the Correct dateTime according to 'MY' system time as that's what i am comparing against and want to store in my MySQL db as well. (as reported from PHP).
Now the problem is, i exported a MySQL db to PDF format, just to see what it looked like, and the time was 1 hour back, ex.. it was (10:00 a.m.) here and the PDF footer said (9:00 a.m.)
So.. i got to thinking.. my PHP script will INSERT into the db the correct dateTime that i need.. But i have alot of dateTime comparing going on for accounts,
I know if i run any MySQL Queries in phpMyAdmin then i will get the wrong dateTime.
i have tried running in (phpMyAdmin SQL Query)
SET time_zone = 'America/New_York';
-and-
SET time_zone = '-05:00';
But when I run the query
SELECT ##global.time_zone, ##session.time_zone;
I get back SYSTEM and SYSTEM.
(I should also mention i am on shared hosting)
If I use the MySQL NOW() function in my query, the time entered into the db will be calculated by MySQL, according to it's own timezone.
like this..
mysql_query("INSERT INTO table (id, value, time_created)
VALUES ('{$id}', '{$value}', NOW())");
I understand that I will have to do all of my INSERTING and comparing in PHP to keep the times right.. but with the above, it will insert the wrong time.
so this is my dilemma...
But will this affect anything that i am not foreseeing? I just feel like somehow this will affect my times.
So how can I get around this or get MySQL on the SAME timezone? and make sure that ALL my date/times are right, not the 1 hour behind..
Two queries ran successively through PhpMyAdmin will be executed in two separate sessions (connections) therefore SELECT ##session.time_zone alone will always return "SYSTEM".
I doubt you can (and I hope you cannot) change the global time zone on a shared server, so always expect "SYSTEM" for SELECT ##global.time_zone. On the other hand you should be able to change your session's time zone.
Try running these two queries in one execution, it should show the new time zone :
SET time_zone = '-05:00'; SELECT ##session.time_zone; -- same session
NOW() returns time in the current session time zone, so time zone does matter. However I would rather store times in GMT time zone, but I suppose that's more a matter of taste.
Depending on what you may do and what you may not do (on your shared hosting) you could choose to either use the following statement as the start of all your queries: "set time_zone='-05:00';", for example: "set time_zone='-05:00'; select foo from bar;" or (maybe the most reliable option): only use timestamps in your tables and queries and create DateTime objects in PHP based on the timestamp you received.

current timestamp = tomorrow

I have recently changed my server time zone to America/New_York.
The problem is when I run my php/mysql script to add rows into the database with default: CURRENT_TIMESTAMP, it adds the date as tomorrow instead of today.
Then when tomorrow rolls over at midnight on my server, the dates go back to yesterday?
MySQL uses its own time zone settings and PHP uses its own time zone settings.
Make sure when you configure your PHP time zone settings, set the same time zone settings for MySQL as well.
Oh and by the way, Timestamp data type in MySQL doesn't store time zone information, If you supply timezone to MySQL when writing to this field, MySQL will convert it to UTC based on its timezone settings.
SELECT ##global.time_zone, ##session.time_zone; -- perform this in mysql console
If it gives incorrect result - change the mysql server timezone explicitly in config file:
http://dev.mysql.com/doc/refman/5.1/en/time-zone-support.html

Categories