ubuntu - timestamps not honoured in PHP-FPM -
i know question serverfault having difficulty logging in.
i have ubuntu instance in cloud running nginx + php5-fpm.
i have set timezone in php.ini asia/singapore
, verified set in phpinfo()
.
i have set os timezone using dpkg-reconfigure tzdata
well.
for time, i've been having trouble wrong dates set in application. thought might did in php setup, in bootstrap script, included:
date_default_timezone_set('asia/singapore');
tried installing timezonedb via pecl suggested in post: setting default timezone not work despite timezone being valid
a user set date set on webform still gets translated "yesterday" when processed. have tried both date()
& gmdate()
in php same results.
edit
a little more information in case.
user selects date
jquery datepicker
on form submission, send timestamp server php process & store. divide timestamp 1000 in php before storing.
<?php $timestamp = (int) $_post['birthday'] / 1000 // received form.
upon echoing date & timestamp,
<?php echo date('ds f y', (int) $timestamp); // when rendering html... // computes 13th april 1981 //js new date(data.timestamp * 1e3).tostring() // exact same timestamp earlier received server. // computes tue apr 14 1981 23:30:00 gmt+0730 (sgt)
any ideas?
your clock assumed in utc/gmt, "humanising"/ conversion string adds time zone offset. http header being in gmt on original value. how unix clocks work, makes global traffic routing possible.
<?php # locale configured 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 reporting correct time in utc. fix, emit header inside php? override first value...
header("date: ".date('r', time()+8*60*60));
edit
as changed question, more text response...
i think necessary confirm date-as-int operations done utc/gmt time. if user in in singapore time sent server in +8h offset. transmitting text or int? of jquery dates have used return string. if unpack via strtotime(), corrects time offset.
the /1000 should have no computation significance, 8h = (60*60*8)s = 28800s >1000.
what client timezone ~ gettimezoneoffset
it looks 1 of convert-to-int operations didn't remove timezone offset.
Comments
Post a Comment