Did you build both yourself?

Note that some distros link PHP against their own timezone db and if it differs from the one we bundle you will see results like this. If you build the same version of PHP yourself on both systems you should see the same result.

I can't see which timezone is set on the two servers. 358 seconds difference look like some issue with a timezone. 

Please check:
 * Timezone on the servers (date_default_timezone_get())
 * Which version of the timezonedb is installed (and linked to PHP) on the servers (php -i | grep Olson)

The Server
PHP 5.5.9 (cli) (built: Dec  7 2015 15:37:14) 
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
    with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies

date/time support => enabled
"Olson" Timezone Database Version => 2013.9
Timezone Database => internal
Default timezone => Asia/Shanghai
date.timezone => Asia/Shanghai => Asia/Shanghai

The Local
PHP 7.0.15-0ubuntu0.16.04.4 (cli) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
    with Zend OPcache v7.0.15-0ubuntu0.16.04.4, Copyright (c) 1999-2017, by Zend Technologies

date/time support => enabled
"Olson" Timezone Database Version => 0.system
Timezone Database => internal
Default timezone => Asia/Shanghai
date.timezone => Asia/Shanghai => Asia/Shanghai

my doubt is why there is chasm between 1927-12-31 23:54:02(1325491915) and 1927-12-31 23:54:03(1325491557)

You stumbled over one of these strange offset issues in the TZ-Database: Have a look at https://github.com/eggert/tz/blob/68efd697628085f6461f66d8429431175f91c09a/asia#L395 - that adds an offset of 8 hours 5 minutes and 57 seconds to UTC on the 1st of january 1928 at exactly 00:00:00. So 1927-12-31 23:54:02 needs to be followed by 1928-1-1 00:00:00 which - due to it being a time before the epoch - will be calculated back to a timestamp that seems to be weird.

So it's not a bug in PHP as PHP is doing the calculations absolutely correct (hence I'm closing this). But it's an issue in the Timezone-Database that has been altered with https://github.com/eggert/tz/commit/15b01c042afa770acd5068054c50e7c5c663cbd2 in 2014. 

Due to your server using a rather outdated Timezone-Database and your dev-machine using the systems (up to date) version you get this mismatch. You should update your timezonedb on the server by either updating the PHP-Version or at least by updating the timezonedb using https://pecl.php.net/package/timezonedb

I use the same timezonedb version, Set the same timezone Asia/Shanghai, Compile with the different php version, But it does't work, It seems only can to update php version to sovle the problem;


timezonedb https://pecl.php.net/get/timezonedb-2017.2.tgz

php5.5 http://php.net/get/php-5.5.38.tar.gz/from/a/mirror
php5.6 http://php.net/get/php-5.6.30.tar.gz/from/a/mirror
php7.0 http://php.net/get/php-7.0.17.tar.gz/from/a/mirror

➜  bin /data/service/php5.5/bin/php /data/www/test/test.php
-2209017943
2017-03-26 09:49:39
2017.2
➜  bin /data/service/php5.6/bin/php /data/www/test/test.php
-2209017600
2017-03-26 09:49:45
2017.2
➜  bin /data/service/php7.0/bin/php /data/www/test/test.php
-2209017600
2017-03-26 09:49:52
2017.2
➜  bin