I been breaking my brain about this one…
Server Location: San Francisco
Server Configuration: Ubuntu + LEMP
App: Wordpress
Ok so I set Ubuntu's time to my current time and changed the time zone to HST which is the one Im at and restarted cron.
I set the php.ini timezone to Pacific/Honolulu and set Wordpress Settings/Timezone to Pacific/Honolulu
Restarted nginx and php...
However when I
<?php echo date('e'); ?>
it displays UTC…
am I missing anything? help!
Try following,
<?php
date_default_timezone_set('America/Los_Angeles');
echo date_default_timezone_get() . ' => ' . date('e') . ' => ' . date('T');
?>
Set the timzone within the script.
date_default_timezone_set('PST');
date('e');
What was your system timezone set to when you've originally started nginx?
Did you actually shutdown nginx, and then started it up from scratch, or did you simply made it re-read its configuration file? (FYI: the popular cat /var/run/nginx.pid | xargs kill -HUP would not result in a restart.)
Your best bet would probably be to do something like sudo sh -c "cat /usr/share/zoneinfo/Pacific/Honolulu > /etc/localtime", remove any timezone mentions from the individual apps, and then properly shutdown and startup the whole server.
In your php.ini file make sure you set:
date.timezone = "America/Los_Angeles"
And then change your server time to the appropriate timezone using:
sudo dpkg-reconfigure tzdata
Better late than never, so I'll chime in here. It's actually WordPress and the weird decision to set the default timezone back to UTC no matter what your INI settings might be. This delightful gem can be found in wp-settings.php (link is for trunk version, marked line might be off in the future).
I guess they did it to keep their internal time calculations easy and on a common base. I do understand the intention behind this but still think it's awkward and surely has caused lots of confusion and trouble for users and developers (like me just now). They could've kept it internal.
Anyways, the bottom line is: When doing your own time calculations in a theme or plug-in or whatever, be sure to explicitly set the timezone beforehand.
Just using time() and thinking you're good to go might lead to headaches. You can get what is set in the settings panel via get_option('timezone_string') and for example use that in conjunction with date_default_timezone_set.
Weston Ruter summed this all up just fine and also suggests using PHP's date and time related classes and explicitly setting the timezone for them.
Related
I have been running PHP on many Ubuntu versions and all of them exhibit the same "feature". When I dump the output of the phpinfo() function to a web page, I see the following:
Default timezone: Europe/Moscow
when both php.ini files (/etc/php/7.?/apache2/php.ini and /etc/php/7.?/cli/php.ini) have the date.timezone setting commented out, as it is the case by default.
My system's time zone has always been set correctly to Europe/Istanbul:
$ file /etc/localtime
/etc/localtime: symbolic link to /usr/share/zoneinfo/Europe/Istanbul
However, PHP thinks my local time zone is Europe/Moscow instead. Currently, these two time zones are similar, but this was not so in the past and may not be so in the future.
To solve, this problem each time these php.ini files are being updated (for example, after a patch or system upgrade) I have to manually edit them and set:
date.timezone = Europe/Istanbul
What is the reason of this strange behavior and what can I do to solve this problem?
Currently, I am on Ubuntu 19.10 with PHP 7.3, but the problem exists in previous OS and PHP versions too.
You said yourself that Moscow and Istanbul are in the same timezone. If you are worried that your PHP programs may suffer functionality in the event that this were to ever change you can may use the function
date_default_timezone_set ( string $timezone_identifier ) : bool
to override the php.ini file. I have included a link to the documentation.
I'm using MAMP on a MacBook Pro, and whenever I took a look into the php_error.log I get each error with a timestap from Berlin but I'm in South America.
[16-Jan-2016 03:06:40 Europe/Berlin] PHP Parse error:
The actual time when that error happened was 21:06.
how can I change this timestamp? I know is not a big deal but is easier to debug when the date is correct.
The timezone is indeed set to Berlin somewhere in your system or code.
Check /usr/local/etc/php/(version)/php.ini file and look for date.timezone setting. A full list of supported timezones is available here. Modify this setting if necessary and restart your PHP process/server. Even if the setting was not present, it's a good idea to fix that now!
Check if 'Europe/Berlin' is set somewhere in your code. Simple way to look in all PHP files in the folder:
find . -name "*.php" -exec grep -H "Europe/Berlin" {} \;
Here's to change the timezone
<?php
date_default_timezone_set('America/Los_Angeles'); //example
?>
Here's the link PHP Set Timezone
My date.php is -
<?php
echo date('Y');
When I execute php -f date.php on my staging machine, I get error -
PHP Fatal error: date(): Timezone database is corrupt - this should *never* happen!
in /home/staging/test/date.php on line 2
But when I execute the same on my local / dev machine it works. Although on both staging and local machines, permissions on /etc/localtime and /usr/share/zoneinfo/ are the same.
But output of file /etc/localtime vary on both machines.
Local (php5.3.5) :
/etc/localtime: timezone data, version 2, 4 gmt time flags, 4 std time flags, no leap seconds, 4 transition times, 4 abbreviation chars
Staging (php5.3.10) :
/etc/localtime: timezone data, version 2, 1 gmt time flag, 1 std time flag, no leap seconds, no transition times, 1 abbreviation char
While trying to find what the issue is I found this link from SO. I am confused over the accepted answer. My apache user is not executing the script.
What seems to be the problem? How do I resolve this issue?
For various reasons, PHP ships with its own timezone database - it is possible to use the system TZDB by configuring the software differently at compile time.
The PHP timezonedb is implemented as C code (lots of defines) - hence you need to recompile PHP to get it working.
If your PHP interpreter is not explicitly configured to use the OS timezoneDB, then you really need to investigate why the executable is corrupt.
Please check permission of your timezone files.It might have changed when you have install some rpms.
change the permission to 655
Also check following files:
/usr
/lib
/share
/etc
My problem was that I was running php-fpm in chroot mode. I changed it to run without a chroot, and then the error went away.
PHP date() & time() return incorrect time:
When date.timezone = "Europe/Riga" the time returned by date() was 03-12-2011 08:57:12, but system time was 03-12-2011 01:57:12 (timezone Europe/Riga - correct time at that moment).
When I changed timezone to "Europe/London", the time changed to 03-12-2011 06:57:12 ( actual time 02-12-2011 23:57:12 )
Time returned by date / hwclock --show was correct (03-12-2011 01:57:12 with system timezone set as Riga)
OS: Debian 6.0
I have checked most of the questions regarding similar issues on SO/Google, but they all seem to have wrong timezone specified.
As far as I can tell there is problem between php -> os.
Of course, because the incorrect time offset is always constant I could subtract difference, but it is not a proper solution.
Any ideas will be greatly appreciated.
Reading PHP manual seems that behaviour of date.timezone is affected by settings in php.ini.
There is another way to set the default timezone in all date/time function and it's the date_default_timezone_set. Try to set it with:
date_default_timezone_set('Europe/Riga');
instead of your date.timezone code.
The problem looks similar to what I have seen on one of my servers. Looks to like bug in php 5.3.2-1. Try to run the php script in the bug report and post your results.
The timezone of the system could be wrong. This results in a shift in a time given by the PHP date() function, althought both php date.timezone (in php.ini) and system time of the server are correct.
I had some problem with timezone too. This can be handy for someone.
In my case, Chile Sumer Time CLST returned wrong timzeone offset.
Updating the timezonedb worked for me.
Go to: https://pecl.php.net/package/timezonedb
For Widnows Download the newest version of dll, copy into "ext" directory. Edit the php.ini and put below line:
extension=php_timezonedb.dll
For Linux You can use :
pecl install timezonedb
and in php.ini put:
extension=php_timezonedb.so
This comment for Azerbaijan timezone
I have problem with 'Asia/Baku' on php 7.2 or php 7.1 version.
I solved problem change to 'Europe/Baku'
You have to set date.timezone in php.ini and restart your server
http://php.net/manual/en/timezones.php
PHP time is based on epoch time scale which uses GMT and later UTC. Most people now refer to it as unix time. Because PHP uses unix time, timezones are not used. I believe subtracting the timezone hours in seconds is the correct method to adjust for the differences.
When checking php.ini, from both phpinfo and php -i on the command line, my timezone is set to Africa/Johannesburg. So my timezone is GMT +2.
I wrote a tiny snippet to check the time is right as follows:
echo date('h:i A', time());
echo '<br />' . ini_get('date.timezone');
and this outputs the correct time, matching with my localmachine's system time.
However, when I look at my php error log, the time on each error log item is behind by exactly two hours? Why is this, and how can I fix this.
Also having issues with Zend Cache, and i think this time issue is causing it.
It sounds like PHP is configure with one timezone, and the server it is running on is set to a different time zone (possibly GMT / UTC). This means all file operations etc will be working on a different timezone to your PHP scripts.
Check the system timezone of your server.
Google-fu: read what the PHP official site writes.