Timestamp.strftime() has erratic behavior after use of tz_convert()
#### Code Sample, a copy-pastable example if possible

```python
# let's first create a Timestamp and assign it to a timezone
>>> import pytz
>>> from pytz import timezone
>>> import pandas as pd
>>> dtest = pd.to_datetime("Sunday, July 28, 2018 10:00 AM", infer_datetime_format=True).replace(tzinfo=timezone('America/New_York')) # okay, this should uniquely represent a point in time
>>> dtest
Timestamp('2018-07-28 10:00:00-0400', tz='America/New_York') # yup, that's the time - 10AM at GMT-0400.
>>> dtest2 = dtest.tz_convert('UTC') # now tz_convert to UTC
>>> dtest2
Timestamp('2018-07-28 14:00:00+0000', tz='UTC') # yup, still same point in time, just different time zone now
>>> dtest3 = dtest.tz_convert('Asia/Tokyo')
>>> dtest3
Timestamp('2018-07-28 23:00:00+0900', tz='Asia/Tokyo') # still same point in time
>>> dtest.strftime('%s') # let's convert to unix time - this one looks right
'1532786400'
>>> dtest2.strftime('%s') # should be the same, but it's not.
'1532804400'
>>> dtest3.strftime('%s') # same goes for another timezone
'1532836800'
>>> dtest.timestamp() # but .timestamp() works fine!
1532786400.0
>>> dtest.strftime('%s') == str(int(dtest.timestamp()))
True
>>> dtest2.timestamp()
1532786400.0
>>> dtest2.strftime('%s') == str(int(dtest2.timestamp()))
False
>>> dtest3.timestamp()
1532786400.0
>>> dtest3.strftime('%s') == str(int(dtest3.timestamp()))
False
```
#### Problem description

(N.B.: tested from a machine on US-Eastern time, currently GMT-0500)

When a Timestamp has been `tz_convert()`'d to another timezone, casting it back to a UNIX timestamp using `strftime('%s')` results in an erroneous output.  The amount of the error appears to be correlated to the hours of the timezone shift, but maybe also to the current GMT offset of the interactive machine - it's inconsistent and I haven't found a definitive pattern yet.

the `%s` parameter in `strftime()` is a documented parameter in the underlying C library, as seen in [Linux man pages](http://man7.org/linux/man-pages/man3/strftime.3.html), and it works fine in the implementation in `datetime.strftime()`.  But, perhaps, not within Pandas' `Timestamp.strftime()`.

Enough people need their dates to be represented in UNIX timestamps (e.g. for reasons of interoperability with other systems) that having this as a working function is valuable, because it's the first function people will think to use when trying to format a time into some other representation.  And better for it to not work at all than to return bad data.  Having `.timestamp()` is useful, but does not reduce the value of fixing this bug.

Regardless, however:

#### Expected Output

We would expect this line to yield `True` regardless of whatever `tz_convert()` operations have been made upon a Timestamp object:
`>>> dtest.strftime('%s') == str(int(dtest.timestamp()))`

But what is happening instead is that any `tz_convert()` operation other than to the same timezone it's already in, changes the unix timestamp output by `strftime("%s")`.

#### Output of ``pd.show_versions()``

<details>

>>> pd.show_versions()

INSTALLED VERSIONS
------------------
commit: None
python: 2.7.12.final.0
python-bits: 64
OS: Darwin
OS-release: 18.2.0
machine: x86_64
processor: i386
byteorder: little
LC_ALL: None
LANG: en_US.UTF-8
LOCALE: None.None

pandas: 0.23.4
pytest: None
pip: 18.1
setuptools: 40.6.3
Cython: None
numpy: 1.15.4
scipy: 1.2.0
pyarrow: None
xarray: None
IPython: None
sphinx: None
patsy: None
dateutil: 2.7.5
pytz: 2018.9
blosc: None
bottleneck: None
tables: None
numexpr: None
feather: None
matplotlib: 1.3.1
openpyxl: None
xlrd: 1.2.0
xlwt: None
xlsxwriter: None
lxml: None
bs4: 4.7.1
html5lib: None
sqlalchemy: 1.2.15
pymysql: None
psycopg2: None
jinja2: 2.10
s3fs: None
fastparquet: None
pandas_gbq: None
pandas_datareader: None

</details>
