CONVERT_TIMEZONE in redshift is producing the opposite result as expected

Viewed 1649

According to the Redshift Documentation, the syntax should be as follows:

CONVERT_TIMEZONE ( ['source_timezone',] 'target_timezone', 'timestamp')

This seems to work fine with standard time zone names, however it doesn't seem to work propoerly when the source timezone is specified as UTC+/- some numbers. In fact it seems to just be working backward.

I am trying to run the following query, for example:

select convert_timezone('UTC','UTC-8','2019-01-01 00:00:0000')

The expected result is that this should subtract 8 hours from my timestamp because going from UTC (source) to UTC-8 should take off 8 hours. Instead it is adding 8 hours, and my result is 2019-01-01 08:00:00.000000. Why is this happening? Alternatively, converting to a named timezone works as intended:

select convert_timezone('UTC','America/Los_Angeles','2019-01-01 00:00:0000')

This query properly displays 2018-12-31 16:00:00.00000 as the result.

So why is it that this function is working backwards? An obvious workaround is to just structure my query backwards, but that seems like an awkward solution. And I would just use a named timezone, but none of the named time zones are explicitly UTC-8 that I know of (Los Angeles for example is GMT-7 during PDT, so that won't work).

1 Answers

Redshift timezone offsets react opposite to their mathematical operator. Another way to think about it is losing (-) time and gaining (+) time relative to yourself. If you traveled from a UTC timezone to America/Los_Angeles timezone, the clock goes back causing you personally to gain (+) eight hours (a whole extra day in the sun!).

Related