红移中的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 (例如洛杉矶在PDT期间是GMT-7，所以这是行不通的)。

Answer 1

红移时区偏移量与它们的数学运算符相反。另一种思考它的方法是相对于自己来说，失去(-)时间和获得(+)时间。如果您从UTC时区到美国/洛杉矶时区旅行，那么时钟将返回，从而使您个人获得(+) 8个小时(在阳光下多呆一天！)。