Interestingly enough, only happens with the shorter timezone names (PDT, PST) and not the longer ones (America/Los_Angeles):

<?php

$now = new \DateTime ('@1460394772');
$now -> setTimezone (new \DateTimeZone ('PDT'));

printf ("(PDT) now->format('U'): %s\n", $now -> format ('U'));
$now -> getTimestamp();
printf ("(PDT) now->format('U'): %s\n", $now -> format ('U'));

echo "\n";

$now = new \DateTime ('@1460394772');
$now -> setTimezone (new \DateTimeZone ('America/Los_Angeles'));

printf ("(America/Los_Angeles) now->format('U'): %s\n", $now -> format ('U'));
$now -> getTimestamp();
printf ("(America/Los_Angeles) now->format('U'): %s\n", $now -> format ('U'));



Expected
--------------
(PDT) now->format('U'): 1460394772
(PDT) now->format('U'): 1460394772

(America/Los_Angeles) now->format('U'): 1460394772
(America/Los_Angeles) now->format('U'): 1460394772


Actual
-------------
(PDT) now->format('U'): 1460365972
(PDT) now->format('U'): 1460394772

(America/Los_Angeles) now->format('U'): 1460394772
(America/Los_Angeles) now->format('U'): 1460394772




I am not actually sure which timestamp I would expect to see (1460365972 or 1460394772) - but I am 100% sure I would not expect to get a different value back after calling getTimestamp()

It is worth noting, the example illustrates that the comparison works as expected *after* calling `$now->getTimeStamp()`.

From the source, it looks likes the compare function conditionally invokes `timelib_update_ts()`.  By comparison, `date_timestamp_get` unconditionally invokes `timelib_update_ts()`.

This suggests that the value of `o2->time->sse_uptodate` is incorrect in the described scenario. 

Reference: 

https://github.com/php/php-src/blob/PHP-5.6.20/ext/date/php_date.c#L2192
static int date_object_compare_date(zval *d1, zval *d2 TSRMLS_DC)
{
	...
	if (!o1->time->sse_uptodate) {
		timelib_update_ts(o1->time, o1->time->tz_info);
	}
	if (!o2->time->sse_uptodate) {
		timelib_update_ts(o2->time, o2->time->tz_info);
	}
        ....
}

https://github.com/php/php-src/blob/PHP-5.6.20/ext/date/php_date.c#L3645
PHP_FUNCTION(date_timestamp_get)
{
	...
	timelib_update_ts(dateobj->time, NULL);
        ...
}

Expanding on the point made by cmshelto at gmail dot com...

The same exact (incorrect) behavior occurs when using offsets for the timezone:

Test script:
------------
<?php

$now = new \DateTime ('@1460394772');
$now -> setTimezone (new \DateTimeZone ('-0700'));

printf ("(PDT) now->format('U'): %s\n", $now -> format ('U'));
$now -> getTimestamp();
printf ("(PDT) now->format('U'): %s\n", $now -> format ('U'));

echo "\n";

$now = new \DateTime ('@1460394772');
$now -> setTimezone (new \DateTimeZone ('America/Los_Angeles'));

printf ("(America/Los_Angeles) now->format('U'): %s\n", $now -> format ('U'));
$now -> getTimestamp();
printf ("(America/Los_Angeles) now->format('U'): %s\n", $now -> format ('U'));



Expected
--------------
(PDT) now->format('U'): 1460394772
(PDT) now->format('U'): 1460394772

(America/Los_Angeles) now->format('U'): 1460394772
(America/Los_Angeles) now->format('U'): 1460394772


Actual
-------------
(PDT) now->format('U'): 1460365972
(PDT) now->format('U'): 1460394772

(America/Los_Angeles) now->format('U'): 1460394772
(America/Los_Angeles) now->format('U'): 1460394772


The two incorrect cases have a common code path in `timelib_unixtime2local()`.  In the case of `America/Los_Angeles`, there is special logic to reset `tm->sse` to counter the fact that an earlier call to `timelib_unixtime2gmt()` modifies it.  The other two cases (TZ-as-abbreviation, TZ-as-offset) do not do this.

So far, this is the only place that I have been able to find which:

1) Manipulates `time->sse`
2) Follows the same code path for abbreviation and offset timezones
3) Follows a different path for timezone ids (e.g. `America/Los_Angeles`)

Code reference for my earlier comment about suspect code path:

https://github.com/php/php-src/blob/master/ext/date/lib/unixtime2tm.c#L179
void timelib_unixtime2local(timelib_time *tm, timelib_sll ts)
{
	...
	switch (tm->zone_type) {
		case TIMELIB_ZONETYPE_ABBR:
		case TIMELIB_ZONETYPE_OFFSET: {
			int z = tm->z;
			signed int dst = tm->dst;

			timelib_unixtime2gmt(tm, ts - (tm->z * 60) + (tm->dst * 3600));

			tm->z = z;
			tm->dst = dst;
			break;
		}

		case TIMELIB_ZONETYPE_ID:
			gmt_offset = timelib_get_time_zone_info(ts, tz);
			timelib_unixtime2gmt(tm, ts + gmt_offset->offset);

			/* we need to reset the sse here as unixtime2gmt modifies it */
			tm->sse = ts;
			tm->dst = gmt_offset->is_dst;
			tm->z = gmt_offset->offset;
			tm->tz_info = tz;

			timelib_time_tz_abbr_update(tm, gmt_offset->abbr);
			timelib_time_offset_dtor(gmt_offset);
			break;

		default:
			tm->is_localtime = 0;
			tm->have_zone = 0;
			return;
	}
        ...
}

From the documentation[1]:

| Please do not use any of the timezones listed here (besides
| UTC), they only exist for backward compatible reasons, and may
| expose erroneous behavior.

So this is not a bug.

[1] <https://www.php.net/manual/en/timezones.others.php>