All these examples should return "2019-05-22T16:00:00Z", but they all return "2019-05-22T12:00:00Z" instead. I've indicated the "TS" comment from setTimestamp() responsible for each example.
-- TS_POSTGRES (the first one) >>> Wikimedia\Timestamp\ConvertibleTimestamp::convert( TS_ISO_8601, '2019-05-22 12:00:00-04' ) => "2019-05-22T12:00:00Z" -- TS_RFC2822 >>> Wikimedia\Timestamp\ConvertibleTimestamp::convert( TS_ISO_8601, 'Wed, 22 May 2019 12:00:00 -0400' ) => "2019-05-22T12:00:00Z" -- TS_RFC850 >>> Wikimedia\Timestamp\ConvertibleTimestamp::convert( TS_ISO_8601, 'Wednesday, 22-May-19 12:00:00 EDT' ) => "2019-05-22T12:00:00Z"
Oddly, though,
-- TS_POSTGRES (the first one) >>> Wikimedia\Timestamp\ConvertibleTimestamp::convert( TS_UNIX, '2019-05-22 12:00:00-04' ) => "1558526400" -- TS_RFC2822 >>> Wikimedia\Timestamp\ConvertibleTimestamp::convert( TS_UNIX, 'Wed, 22 May 2019 12:00:00 -0400' ) => "1558540800" -- TS_RFC850 >>> Wikimedia\Timestamp\ConvertibleTimestamp::convert( TS_UNIX, 'Wednesday, 22-May-19 12:00:00 EDT' ) => "1558540800" -- asctime format, which isn't supposed to have a timezone -- https://pubs.opengroup.org/onlinepubs/9699919799/functions/asctime.html >>> Wikimedia\Timestamp\ConvertibleTimestamp::convert( TS_UNIX, 'Wed May 22 12:00:00 2019 -0400' ) => "1558540800"
It honored the timezone when the output format is TS_UNIX, except for when the input was TS_POSTGRES‽
In general, if we accept input with a timezone then we should honor that in all output. If we're not going to honor it in all output, we shouldn't honor it in any output and we should reject input with a non-UTC zone.