Apache Flink 中文用户邮件列表

关于 SQL DATE_FORMAT 的时区设置的构想

Classic

List

Threaded

7 messages Options

DONG, Weike

关于 SQL DATE_FORMAT 的时区设置的构想

Hi,

近期发现 Flink 的 Blink Planner 在 DATE_FORMAT 对 CURRENT_TIMESTAMP
做时间格式化为字符串时，默认以 UTC+0 为准。

长期以来，TableConfig 类里面有一个 setLocalTimeZone 方法；将其设置为东八区以后，发现格式化后的字符串仍然是 UTC+0
的。而深入来看，Flink 的时间格式化时的代码生成逻辑（time.scala）并未考虑时区的设置。

由于大多数用户的时区均不是 UTC+0（GMT、UTC），如果时间格式化、显示等都可以考虑到 TableConfig 中的时区设置，那么 Flink
是否会更用户友好一些呢？当然这个会涉及到不兼容的变更，需要谨慎一些。

也许提供一个 DATE_FORMAT_WITH_TIMEZONE 的内置函数，社区是否会更容易接受一些呢？

仅仅是个人一点想法，感谢：）

Zhenghua Gao

Re: 关于 SQL DATE_FORMAT 的时区设置的构想

CURRENT_TIMESTAMP 返回值类型是 TIMESTAMP (WITHOUT TIME ZONE)，
其语义可参考 java.time.LocalDateTime。
其字符形式的表示并不随着时区变化而变化(如你所见，和UTC+0 一致)。

你的需求可以通过 CONVERT_TZ(timestamp_string, time_zone_from_string,
time_zone_to_string)

*Best Regards,*
*Zhenghua Gao*

On Mon, Mar 23, 2020 at 10:12 PM DONG, Weike <[hidden email]>
wrote:

> Hi,
>
> 近期发现 Flink 的 Blink Planner 在 DATE_FORMAT 对 CURRENT_TIMESTAMP
> 做时间格式化为字符串时，默认以 UTC+0 为准。
>
> 长期以来，TableConfig 类里面有一个 setLocalTimeZone 方法；将其设置为东八区以后，发现格式化后的字符串仍然是 UTC+0
> 的。而深入来看，Flink 的时间格式化时的代码生成逻辑（time.scala）并未考虑时区的设置。
>
> 由于大多数用户的时区均不是 UTC+0（GMT、UTC），如果时间格式化、显示等都可以考虑到 TableConfig 中的时区设置，那么 Flink
> 是否会更用户友好一些呢？当然这个会涉及到不兼容的变更，需要谨慎一些。
>
> 也许提供一个 DATE_FORMAT_WITH_TIMEZONE 的内置函数，社区是否会更容易接受一些呢？
>
> 仅仅是个人一点想法，感谢：）
>

DONG, Weike

Re: 关于 SQL DATE_FORMAT 的时区设置的构想

Hi Zhenghua,

感谢您的回复。感觉既然 Flink 已经提供了时区的设定，这方面也许可以进一步增强一些。CONVERT_TZ
用户很容易忘记或者漏掉，这里还是有不少完善的空间。

Best,
Weike

On Tue, Mar 24, 2020 at 4:20 PM Zhenghua Gao <[hidden email]> wrote:

> CURRENT_TIMESTAMP 返回值类型是 TIMESTAMP (WITHOUT TIME ZONE)，
> 其语义可参考 java.time.LocalDateTime。
> 其字符形式的表示并不随着时区变化而变化(如你所见，和UTC+0 一致)。
>
> 你的需求可以通过 CONVERT_TZ(timestamp_string, time_zone_from_string,
> time_zone_to_string)
>
> *Best Regards,*
> *Zhenghua Gao*
>
>
> On Mon, Mar 23, 2020 at 10:12 PM DONG, Weike <[hidden email]>
> wrote:
>
> > Hi,
> >
> > 近期发现 Flink 的 Blink Planner 在 DATE_FORMAT 对 CURRENT_TIMESTAMP
> > 做时间格式化为字符串时，默认以 UTC+0 为准。
> >
> > 长期以来，TableConfig 类里面有一个 setLocalTimeZone 方法；将其设置为东八区以后，发现格式化后的字符串仍然是
> UTC+0
> > 的。而深入来看，Flink 的时间格式化时的代码生成逻辑（time.scala）并未考虑时区的设置。
> >
> > 由于大多数用户的时区均不是 UTC+0（GMT、UTC），如果时间格式化、显示等都可以考虑到 TableConfig 中的时区设置，那么
> Flink
> > 是否会更用户友好一些呢？当然这个会涉及到不兼容的变更，需要谨慎一些。
> >
> > 也许提供一个 DATE_FORMAT_WITH_TIMEZONE 的内置函数，社区是否会更容易接受一些呢？
> >
> > 仅仅是个人一点想法，感谢：）
> >
>

Jark

Re: 关于 SQL DATE_FORMAT 的时区设置的构想

Administrator

Thanks for reporting this Weike.

首先，我觉得目前 Flink 返回 TIMESTAMP WITHOUT TIME ZONE 应该是有问题的。
因为 SQL 标准（SQL:2011 Part 2 Section 6.32）定义了返回类型是 WITH TIME ZONE。
另外 Calcite 文档中 [1] 也说返回的是 TIMESTAMP WITH TIME ZONE (虽然好像和实现不一致)
其他的一些数据库也都差不多：mysql [2], oracle[3]

Best,
Jark

[1]: https://calcite.apache.org/docs/reference.html#datetime-functions
[2]:
https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_current-timestamp
[3]:
https://docs.oracle.com/cd/B28359_01/server.111/b28286/functions038.htm#SQLRF00629

On Tue, 24 Mar 2020 at 17:00, DONG, Weike <[hidden email]> wrote:

> Hi Zhenghua,
>
> 感谢您的回复。感觉既然 Flink 已经提供了时区的设定，这方面也许可以进一步增强一些。CONVERT_TZ
> 用户很容易忘记或者漏掉，这里还是有不少完善的空间。
>
> Best,
> Weike
>
> On Tue, Mar 24, 2020 at 4:20 PM Zhenghua Gao <[hidden email]> wrote:
>
> > CURRENT_TIMESTAMP 返回值类型是 TIMESTAMP (WITHOUT TIME ZONE)，
> > 其语义可参考 java.time.LocalDateTime。
> > 其字符形式的表示并不随着时区变化而变化(如你所见，和UTC+0 一致)。
> >
> > 你的需求可以通过 CONVERT_TZ(timestamp_string, time_zone_from_string,
> > time_zone_to_string)
> >
> > *Best Regards,*
> > *Zhenghua Gao*
> >
> >
> > On Mon, Mar 23, 2020 at 10:12 PM DONG, Weike <[hidden email]>
> > wrote:
> >
> > > Hi,
> > >
> > > 近期发现 Flink 的 Blink Planner 在 DATE_FORMAT 对 CURRENT_TIMESTAMP
> > > 做时间格式化为字符串时，默认以 UTC+0 为准。
> > >
> > > 长期以来，TableConfig 类里面有一个 setLocalTimeZone 方法；将其设置为东八区以后，发现格式化后的字符串仍然是
> > UTC+0
> > > 的。而深入来看，Flink 的时间格式化时的代码生成逻辑（time.scala）并未考虑时区的设置。
> > >
> > > 由于大多数用户的时区均不是 UTC+0（GMT、UTC），如果时间格式化、显示等都可以考虑到 TableConfig 中的时区设置，那么
> > Flink
> > > 是否会更用户友好一些呢？当然这个会涉及到不兼容的变更，需要谨慎一些。
> > >
> > > 也许提供一个 DATE_FORMAT_WITH_TIMEZONE 的内置函数，社区是否会更容易接受一些呢？
> > >
> > > 仅仅是个人一点想法，感谢：）
> > >
> >
>

Zhenghua Gao

Re: 关于 SQL DATE_FORMAT 的时区设置的构想

Hi Jark,

这里的确是有问题的。
目前的问题是Calcite本身并不支持TIMESTAMP WITH TIME ZONE.

*Best Regards,*
*Zhenghua Gao*

On Tue, Mar 24, 2020 at 11:00 PM Jark Wu <[hidden email]> wrote:

> Thanks for reporting this Weike.
>
> 首先，我觉得目前 Flink 返回 TIMESTAMP WITHOUT TIME ZONE 应该是有问题的。
> 因为 SQL 标准（SQL:2011 Part 2 Section 6.32）定义了返回类型是 WITH TIME ZONE。
> 另外 Calcite 文档中 [1] 也说返回的是 TIMESTAMP WITH TIME ZONE (虽然好像和实现不一致)
> 其他的一些数据库也都差不多：mysql [2], oracle[3]
>
> Best,
> Jark
>
> [1]: https://calcite.apache.org/docs/reference.html#datetime-functions
> [2]:
>
> https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_current-timestamp
> [3]:
>
> https://docs.oracle.com/cd/B28359_01/server.111/b28286/functions038.htm#SQLRF00629
>
>
>
> On Tue, 24 Mar 2020 at 17:00, DONG, Weike <[hidden email]> wrote:
>
> > Hi Zhenghua,
> >
> > 感谢您的回复。感觉既然 Flink 已经提供了时区的设定，这方面也许可以进一步增强一些。CONVERT_TZ
> > 用户很容易忘记或者漏掉，这里还是有不少完善的空间。
> >
> > Best,
> > Weike
> >
> > On Tue, Mar 24, 2020 at 4:20 PM Zhenghua Gao <[hidden email]> wrote:
> >
> > > CURRENT_TIMESTAMP 返回值类型是 TIMESTAMP (WITHOUT TIME ZONE)，
> > > 其语义可参考 java.time.LocalDateTime。
> > > 其字符形式的表示并不随着时区变化而变化(如你所见，和UTC+0 一致)。
> > >
> > > 你的需求可以通过 CONVERT_TZ(timestamp_string, time_zone_from_string,
> > > time_zone_to_string)
> > >
> > > *Best Regards,*
> > > *Zhenghua Gao*
> > >
> > >
> > > On Mon, Mar 23, 2020 at 10:12 PM DONG, Weike <[hidden email]>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > 近期发现 Flink 的 Blink Planner 在 DATE_FORMAT 对 CURRENT_TIMESTAMP
> > > > 做时间格式化为字符串时，默认以 UTC+0 为准。
> > > >
> > > > 长期以来，TableConfig 类里面有一个 setLocalTimeZone 方法；将其设置为东八区以后，发现格式化后的字符串仍然是
> > > UTC+0
> > > > 的。而深入来看，Flink 的时间格式化时的代码生成逻辑（time.scala）并未考虑时区的设置。
> > > >
> > > > 由于大多数用户的时区均不是 UTC+0（GMT、UTC），如果时间格式化、显示等都可以考虑到 TableConfig 中的时区设置，那么
> > > Flink
> > > > 是否会更用户友好一些呢？当然这个会涉及到不兼容的变更，需要谨慎一些。
> > > >
> > > > 也许提供一个 DATE_FORMAT_WITH_TIMEZONE 的内置函数，社区是否会更容易接受一些呢？
> > > >
> > > > 仅仅是个人一点想法，感谢：）
> > > >
> > >
> >
>

Kurt Young

Re: 关于 SQL DATE_FORMAT 的时区设置的构想

我们先改成 timestamp with local zone，如果这个字段的类型在整个query里都没变过，那个 with time
zone的效果也差不多了。

Best,
Kurt

On Wed, Mar 25, 2020 at 8:43 PM Zhenghua Gao <[hidden email]> wrote:

> Hi Jark,
>
> 这里的确是有问题的。
> 目前的问题是Calcite本身并不支持TIMESTAMP WITH TIME ZONE.
>
> *Best Regards,*
> *Zhenghua Gao*
>
>
> On Tue, Mar 24, 2020 at 11:00 PM Jark Wu <[hidden email]> wrote:
>
> > Thanks for reporting this Weike.
> >
> > 首先，我觉得目前 Flink 返回 TIMESTAMP WITHOUT TIME ZONE 应该是有问题的。
> > 因为 SQL 标准（SQL:2011 Part 2 Section 6.32）定义了返回类型是 WITH TIME ZONE。
> > 另外 Calcite 文档中 [1] 也说返回的是 TIMESTAMP WITH TIME ZONE (虽然好像和实现不一致)
> > 其他的一些数据库也都差不多：mysql [2], oracle[3]
> >
> > Best,
> > Jark
> >
> > [1]: https://calcite.apache.org/docs/reference.html#datetime-functions
> > [2]:
> >
> >
> https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_current-timestamp
> > [3]:
> >
> >
> https://docs.oracle.com/cd/B28359_01/server.111/b28286/functions038.htm#SQLRF00629
> >
> >
> >
> > On Tue, 24 Mar 2020 at 17:00, DONG, Weike <[hidden email]>
> wrote:
> >
> > > Hi Zhenghua,
> > >
> > > 感谢您的回复。感觉既然 Flink 已经提供了时区的设定，这方面也许可以进一步增强一些。CONVERT_TZ
> > > 用户很容易忘记或者漏掉，这里还是有不少完善的空间。
> > >
> > > Best,
> > > Weike
> > >
> > > On Tue, Mar 24, 2020 at 4:20 PM Zhenghua Gao <[hidden email]> wrote:
> > >
> > > > CURRENT_TIMESTAMP 返回值类型是 TIMESTAMP (WITHOUT TIME ZONE)，
> > > > 其语义可参考 java.time.LocalDateTime。
> > > > 其字符形式的表示并不随着时区变化而变化(如你所见，和UTC+0 一致)。
> > > >
> > > > 你的需求可以通过 CONVERT_TZ(timestamp_string, time_zone_from_string,
> > > > time_zone_to_string)
> > > >
> > > > *Best Regards,*
> > > > *Zhenghua Gao*
> > > >
> > > >
> > > > On Mon, Mar 23, 2020 at 10:12 PM DONG, Weike <
> [hidden email]>
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > 近期发现 Flink 的 Blink Planner 在 DATE_FORMAT 对 CURRENT_TIMESTAMP
> > > > > 做时间格式化为字符串时，默认以 UTC+0 为准。
> > > > >
> > > > > 长期以来，TableConfig 类里面有一个 setLocalTimeZone
> 方法；将其设置为东八区以后，发现格式化后的字符串仍然是
> > > > UTC+0
> > > > > 的。而深入来看，Flink 的时间格式化时的代码生成逻辑（time.scala）并未考虑时区的设置。
> > > > >
> > > > > 由于大多数用户的时区均不是 UTC+0（GMT、UTC），如果时间格式化、显示等都可以考虑到 TableConfig
> 中的时区设置，那么
> > > > Flink
> > > > > 是否会更用户友好一些呢？当然这个会涉及到不兼容的变更，需要谨慎一些。
> > > > >
> > > > > 也许提供一个 DATE_FORMAT_WITH_TIMEZONE 的内置函数，社区是否会更容易接受一些呢？
> > > > >
> > > > > 仅仅是个人一点想法，感谢：）
> > > > >
> > > >
> > >
> >
>

Jark

Re: 关于 SQL DATE_FORMAT 的时区设置的构想

Administrator

顺便说一下，目前 localtimestamp 的实现看起来是没有问题的。@Dong 你可以先用 localtimestamp 。

在标准里面，以及一些常见数据库中（如 postgres[1], oracle[2])，localtimestamp 是 without time
zone 的实现，
其值是 session zone 看到的值，等于 cast(current_timestamp as timestamp without time
zone)。
所以目前 localtimestamp 的实现应该是没有问题的。

举个例子，理论上，这两个函数的行为应该如下：

> SET time-zone=+08:00

> SELECT CURRENT_TIMESTAMP, LOCALTIMESTAMP;

EXPR$0 | EXPR$1
2020-03-26 09:51:42.299 +08:00 | 2020-03-26 09:51:42.299

目前 Flink 中的 LOCALTIMESTAMP 是符合预期的。

Best,
Jark

[1]:
https://www.postgresql.org/docs/9.5/functions-datetime.html#FUNCTIONS-DATETIME-CURRENT
[2]:
https://docs.oracle.com/cd/B28359_01/server.111/b28286/functions084.htm#SQLRF00660

On Wed, 25 Mar 2020 at 21:46, Kurt Young <[hidden email]> wrote:

> 我们先改成 timestamp with local zone，如果这个字段的类型在整个query里都没变过，那个 with time
> zone的效果也差不多了。
>
> Best,
> Kurt
>
>
> On Wed, Mar 25, 2020 at 8:43 PM Zhenghua Gao <[hidden email]> wrote:
>
> > Hi Jark,
> >
> > 这里的确是有问题的。
> > 目前的问题是Calcite本身并不支持TIMESTAMP WITH TIME ZONE.
> >
> > *Best Regards,*
> > *Zhenghua Gao*
> >
> >
> > On Tue, Mar 24, 2020 at 11:00 PM Jark Wu <[hidden email]> wrote:
> >
> > > Thanks for reporting this Weike.
> > >
> > > 首先，我觉得目前 Flink 返回 TIMESTAMP WITHOUT TIME ZONE 应该是有问题的。
> > > 因为 SQL 标准（SQL:2011 Part 2 Section 6.32）定义了返回类型是 WITH TIME ZONE。
> > > 另外 Calcite 文档中 [1] 也说返回的是 TIMESTAMP WITH TIME ZONE (虽然好像和实现不一致)
> > > 其他的一些数据库也都差不多：mysql [2], oracle[3]
> > >
> > > Best,
> > > Jark
> > >
> > > [1]: https://calcite.apache.org/docs/reference.html#datetime-functions
> > > [2]:
> > >
> > >
> >
> https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_current-timestamp
> > > [3]:
> > >
> > >
> >
> https://docs.oracle.com/cd/B28359_01/server.111/b28286/functions038.htm#SQLRF00629
> > >
> > >
> > >
> > > On Tue, 24 Mar 2020 at 17:00, DONG, Weike <[hidden email]>
> > wrote:
> > >
> > > > Hi Zhenghua,
> > > >
> > > > 感谢您的回复。感觉既然 Flink 已经提供了时区的设定，这方面也许可以进一步增强一些。CONVERT_TZ
> > > > 用户很容易忘记或者漏掉，这里还是有不少完善的空间。
> > > >
> > > > Best,
> > > > Weike
> > > >
> > > > On Tue, Mar 24, 2020 at 4:20 PM Zhenghua Gao <[hidden email]>
> wrote:
> > > >
> > > > > CURRENT_TIMESTAMP 返回值类型是 TIMESTAMP (WITHOUT TIME ZONE)，
> > > > > 其语义可参考 java.time.LocalDateTime。
> > > > > 其字符形式的表示并不随着时区变化而变化(如你所见，和UTC+0 一致)。
> > > > >
> > > > > 你的需求可以通过 CONVERT_TZ(timestamp_string, time_zone_from_string,
> > > > > time_zone_to_string)
> > > > >
> > > > > *Best Regards,*
> > > > > *Zhenghua Gao*
> > > > >
> > > > >
> > > > > On Mon, Mar 23, 2020 at 10:12 PM DONG, Weike <
> > [hidden email]>
> > > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > 近期发现 Flink 的 Blink Planner 在 DATE_FORMAT 对 CURRENT_TIMESTAMP
> > > > > > 做时间格式化为字符串时，默认以 UTC+0 为准。
> > > > > >
> > > > > > 长期以来，TableConfig 类里面有一个 setLocalTimeZone
> > 方法；将其设置为东八区以后，发现格式化后的字符串仍然是
> > > > > UTC+0
> > > > > > 的。而深入来看，Flink 的时间格式化时的代码生成逻辑（time.scala）并未考虑时区的设置。
> > > > > >
> > > > > > 由于大多数用户的时区均不是 UTC+0（GMT、UTC），如果时间格式化、显示等都可以考虑到 TableConfig
> > 中的时区设置，那么
> > > > > Flink
> > > > > > 是否会更用户友好一些呢？当然这个会涉及到不兼容的变更，需要谨慎一些。
> > > > > >
> > > > > > 也许提供一个 DATE_FORMAT_WITH_TIMEZONE 的内置函数，社区是否会更容易接受一些呢？
> > > > > >
> > > > > > 仅仅是个人一点想法，感谢：）
> > > > > >
> > > > >
> > > >
> > >
> >
>