I know this is probably a question for ServerFault but I am having difficulty logging in.
I have an Ubuntu instance in the cloud running Nginx + PHP5-fpm.
I have set the timezone in php.ini to Asia/Singapore and verified it is set in phpinfo().
I have set the OS timezone using dpkg-reconfigure tzdata as well.
For some time, I've been having trouble with wrong dates set in my application. I initially thought this might be something I did in my PHP setup, so in my bootstrap script, I included:
date_default_timezone_set('Asia/Singapore');
Tried installing timezonedb via PECL as suggested in this post:
Setting default timezone does not work despite timezone being valid
A user set date set on a webform still gets translated to "yesterday" when processed. I have tried both date() & gmdate() in PHP with the same results.
Edit
A little more information in case.
User selects a date with jQuery DatePicker
On form submission, I send the timestamp back to the server for PHP to process & store. I divide the timestamp by 1000 in PHP before storing.
<?php $timestamp = (int) $_POST['birthday'] / 1000
// this is received from a form.
Upon echoing the date & timestamp,
<?php echo date('dS F Y', (int) $timestamp);
// when rendering to HTML...
// computes to 13th April 1981
//JS
new Date(data.timestamp * 1e3).toString()
// the exact same timestamp from earlier but received from server.
// computes to Tue Apr 14 1981 23:30:00 GMT+0730 (SGT)
Any ideas?
Your clock is assumed to be in UTC/GMT, but the "humanising"/ conversion to a string adds the time zone offset. The HTTP header being in GMT will be on the original value. This is generally how Unix clocks work, it makes global traffic routing possible.
<?php
# my locale is configured for London
var_dump(time(), date('Y-m-d H:i:s'));
date_default_timezone_set('Asia/Singapore');
var_dump(time(), date('Y-m-d H:i:s')); # MySQL, locale
var_dump(time(), date('r')); # RFC 2822
var_dump(time(), date('c')); # ISO 8601
Your server is reporting the correct time in UTC.
To fix, could you emit that header inside the PHP? This will override the first value...
header("Date: ".date('r', time()+8*60*60));
Edit
As you changed the question, more text response...
I think its necessary to confirm all the date-as-int operations are done with UTC/GMT time.
If your user in in Singapore the time will be sent to the server in +8h offset. Are you transmitting as text or an int? All of the jQuery dates I have used return a string.
If you unpack via strtotime(), it corrects the time offset.
The /1000 should have no computation significance, 8h = (60*60*8)s = 28800s which is >1000.
What does your client say for the timezone ~ gettimezoneoffset
It looks like one of the convert-to-int operations didn't remove the timezone offset.
There was a bug listed and patched in Ubuntu launchpad. timestamps are working after updating PHP. An excerpt of the bug:
[Impact]
A regression of timezone handling between Precise and Quantal means that PHP scripts that depend on the system timezone now use UTC instead. This breaks arbitrary PHP scripts - eg. cactus stops working as expected.
Not affected: 5.3.10-1ubuntu3.4 (Precise)
Affected: 5.4.6-1ubuntu1 (Quantal)
Not affected: 5.4.4-7 (sid)
Workaround: edit /etc/php5/*/php.ini, uncomment the "date.timezone" line and set it to what you need.
[Test Case]
Set a timezone other than UTC using "dpkg reconfigure tzdata".
$ php -r 'echo date_default_timezone_get()."\n";'
Expected results: system timezone (eg. "Europe/London")
Actual results:
PHP Warning: date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are required to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in Command line code on line 1
UTC
(where in this case UTC is the system timezone).
Related
I'm using date function $now=date("Y-m-d H:i:s"); in php 5.6.30,
The browser output is string(19) "2017-04-21 02:54:54",That's abnormal.
php.ini set is date.timezone = PRC
Centos 7 system time:
[root#localhost sync]# date
Fri Apr 21 14:53:20 CST 2017
While I was installed the PHP 7.0.16 in the same system, php.ini has the same config, but the date output normal in date function(is 24 digit time).
Why happen this and how to let the date normal working.
This is a timezone issue.
In your php.ini, you have the timezone PRC (China) set, but your system time output gives the time in CST (Amerika).
In other words:
Your PHP code does actually give you the 24-hour format, but in a different timezone, where it is in fact 02:54:54
If you need to get the time in a different timezone (like UTC), you can set it like that:
date_default_timezone_set('UTC');
If you need a different local timezone, you can read about the possible values in the list of supported timezones in the PHP documentation
try this below code for date timezone
<?php
date_default_timezone_set('Asia/Shanghai');
echo date("Y-m-d H:i:s");
?>
I'm add the code to php.ini date.timezone = Asia/Shanghai,
and install chrony and start it to synchronized. It works.
I have the behavior which is cofusing me:
1. I got rom request some string date "02.07.2014".
2. Trying to convert it to timestamp
strtotime($search->date_from)
it returns me 1404244800. Assumig that my bug is here, I'm trying to check what I get on this url http://www.onlineconversion.com/unix_time.htm and found the Tue, 01 Jul 2014 20:00:00 GMT
It's almost what I need , excluding that 4 hours are lost: it's very bad for me and unexpected.
On top of php script, put
date_default_timezone_set("YourTimeZone");
YourTimeZone can be one of this:
Timezone
The strtotime function relies on the system timezone, unless you set it otherwise.
You can set the timezone using date_default_timezone_set, example:
date_default_timezone_set("America/Phoenix");
strtotime(...);
Also, see the timezone reference
Use this link instead and it will determine your LOCAL time. http://www.epochconverter.com
The 4 hours that you are losing is most-likely due to the fact that you do not have your timezone set. You can either do this in the php.ini file or in your .php file.
In your .php file do this:
date_default_timezone_set("America/New_York"); // if you live in USA on east coast
// For a list of possible arguments, go here: http://php.net/manual/en/timezones.php
Hope this helps.
I'm trying to debug a php date issue I'm having between 2 servers. I'm passing a timestamp through the date() function on both servers, but I'm getting 2 different dates.
Server 1:
date('d-m-Y', 575766000);
// Outputs 30-03-1988 00:00:00
Server 2:
date('d-m-Y', 575766000);
// Outputs 31-03-1988 00:00:00
I've checked the date on both servers, with the "date" command, and they're both set to:
Wed Mar 6 14:42:19 GMT 2013
Any ideas?
You can check the timezone by logging on to the server and looking at /etc/php.ini depending on how your PHP is configured.
date.timezone="America/New_York"
As of PHP 5.3 you are required to set the timezone. Previously this could be left blank.
You have to correct the times of your servers.
PHP takes the time from the server.
if you will try to set the timezone using this:
date_default_timezone_set("America/Chicago");
Then it should work
I am having an issue with "file_put_contents" when i run this code:
file_put_contents("/var/www/html/storage/views/temp", "helllo world");
It saves the file with a time 1hr in the future.
So where dose it get the time?
I have set php.ini date.timezone = "Europe/London" (as per system timezone) and that seems not to help
php.ini date.timezone option specifies which timezone PHP will use internally.
Most Unix/Linux system use UTC as hardware and then set the system clock to a given timezone.
You end-up with three different timezone, but it should be totally transparent.
Your problem may be due by the fact that your system timezone is different than your php timezone.
To check your system timezone, you can do date +%Z
Depending on your need you will either have to change your PHP timezone according to your system timezone, or convert the date of your timestamp to manage your file.
Excepting you've a good reason to do it, I suggest to adjust your php timezone with your system timezone.
file_put_contents gives the file the server time. That means, when looking at the timestamp of the file, the timezone of the server must be taken into account and must eventually be transformed to the timezone of the client.
On my linux machine date outputs: Thu Sep 20 11:23:28 CEST 2012 and thats the timestamp for the file also. When in CST timezone, you have to substract 7 hours from the the timestamp to get the creation time in CST.
You need to handle the timestamp value correctly, when you use it. Examine this:
<?php
$file = __DIR__ . '/test.dat';
file_put_contents($file, "hello world");
print(gmdate('Y-m-d H:i:s T', filectime($file)) . "\n");
print(date('Y-m-d H:i:s T', filectime($file)) . "\n");
Output:
2012-09-20 09:29:17 GMT
2012-09-20 11:29:17 CEST
Depending on the specific date method you use, you can determine the desired output.
I'm trying to troubleshoot and solve this problem:
the server I'm working on (php 5.2.9 on Linux), has the correct local time (America/Buenos_Aires):
user#server [/home/site/public_html]$ date
Mon Nov 1 17:11:14 ART 2010
php.ini is set with date.timezone = "America/Buenos_Aires"
I also tried to set the timezone directly in the script with
<?php
ini_set('display_errors', true);
error_reporting(E_ALL|E_STRICT|E_NOTICE);
//date_default_timezone_set("America/Buenos_Aires");
//echo date_default_timezone_get(), "<br>";
echo "ini: ", ini_get('date.timezone'), "<br>";
$now = date("H:i:s T I");
$nowdate = date("Y-m-d");
echo $nowdate." ".$now;
?>
but to no avail, the result is
ini: America/Buenos_Aires
2010-11-01 18:11:14 ARST 1
when it should read 17:11 (It's consistently one hour ahead). All I've found here and on the web pointed to
date_default_timezone_set (which I tried)
setting date.timezone in php.ini (which it is set)
confusing server time with client time (which I'm not).
Any ideas?
EDIT:
As suggested, I checked and as you can see in the code, PHP thinks it should be applying DST, and Argentina decided to not apply it this year. Any option besides waiting for a patch?
EDIT 2:
I tried dumping the timezones transition as suggested. I got the following:
The timezone America/Buenos_Aires switches to standard time on 20 Mar 2011 # 02:00.
The new GMT offset will be: -10800 (ART)
There was a question a few days back that suggested that PHP hasn't yet got wind of the fact that Argentina got rid of DST only this year. It seems like this decision hasn't made it into the code base yet. (But it was not confirmed, so it's not 100% clear whether this was it.)
Maybe try dumping your time zones the same way to see whether that applies to your PHP version, too.
Update: This indeed seems to be the problem. The best solution I can think of is to use an offset in the time zone, e.g. Etc/GMT-3
Somebody should file a bug with bugs.php.net, there doesn't seem to be one for this.