CONVERT_TIMEZONE в красном смещении дает противоположный результат, как и ожидалось

Question

В соответствии с документацией Redshift синтаксис должен быть следующим:

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

Кажется, это хорошо работает со стандартными именами часовых поясов, однако, похоже, не работаетпредпочтительно, когда часовой пояс источника указан как UTC +/- некоторые цифры. На самом деле, похоже, что он работает в обратном направлении.

Я пытаюсь выполнить следующий запрос, например:

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

Ожидаемый результат заключается в том, что это должновычтите 8 часов из моей отметки времени, потому что переход от UTC (источник) к UTC-8 должен занять 8 часовВместо этого он добавляет 8 часов, и мой результат 2019-01-01 08:00:00.000000. Почему это происходит? Кроме того, преобразование в именованный часовой пояс работает по назначению:

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

Этот запрос правильно отображает 2018-12-31 16:00:00.00000 в качестве результата.

Так почему же эта функция работает в обратном направлении? Очевидный обходной путь - просто структурировать мой запрос в обратном направлении, но это кажется неудобным решением. И я бы просто использовал именованный часовой пояс, но ни один из названных часовых поясов не является явным UTC-8, о котором я знаю (например, в Лос-Анджелесе GMT-7 во время PDT, так что это не будет работать).

Answer 1

Redshift смещения часового пояса реагируют противоположно их математическому оператору. Еще один способ думать об этом - потерять (-) время и набрать (+) времени по отношению к себе. Если вы путешествовали из часового пояса UTC в часовой пояс Америки / Лос-Анджелеса, часы возвращаются на назад , в результате чего вы лично набираете (+) восемь часов (целый дополнительный день на солнце!).