Re: 关于 SQL DATE_FORMAT 的时区设置的构想
顺便说一下，目前 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 wrote: > 我们先改成 timestamp with local zone，如果这个字段的类型在整个query里都没变过，那个 with time > zone的效果也差不多了。 > > Best, > Kurt > > > On Wed, Mar 25, 2020 at 8:43 PM Zhenghua Gao wrote: > > > Hi Jark, > > > > 这里的确是有问题的。 > > 目前的问题是Calcite本身并不支持TIMESTAMP WITH TIME ZONE. > > > > *Best Regards,* > > *Zhenghua Gao* > > > > > > On Tue, Mar 24, 2020 at 11:00 PM Jark Wu 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 > > wrote: > > > > > > > Hi Zhenghua, > > > > > > > > 感谢您的回复。感觉既然 Flink 已经提供了时区的设定，这方面也许可以进一步增强一些。CONVERT_TZ > > > > 用户很容易忘记或者漏掉，这里还是有不少完善的空间。 > > > > > > > > Best, > > > > Weike > > > > > > > > On Tue, Mar 24, 2020 at 4:20 PM Zhenghua Gao > 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 < > > kyled...@connect.hku.hk> > > > > > 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 的内置函数，社区是否会更容易接受一些呢？ > > > > > > > > > > > > 仅仅是个人一点想法，感谢 ：） > > > > > > > > > > > > > > > > > > > > >
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 wrote: > Hi Jark, > > 这里的确是有问题的。 > 目前的问题是Calcite本身并不支持TIMESTAMP WITH TIME ZONE. > > *Best Regards,* > *Zhenghua Gao* > > > On Tue, Mar 24, 2020 at 11:00 PM Jark Wu 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 > wrote: > > > > > Hi Zhenghua, > > > > > > 感谢您的回复。感觉既然 Flink 已经提供了时区的设定，这方面也许可以进一步增强一些。CONVERT_TZ > > > 用户很容易忘记或者漏掉，这里还是有不少完善的空间。 > > > > > > Best, > > > Weike > > > > > > On Tue, Mar 24, 2020 at 4:20 PM Zhenghua Gao 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 < > kyled...@connect.hku.hk> > > > > 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 的内置函数，社区是否会更容易接受一些呢？ > > > > > > > > > > 仅仅是个人一点想法，感谢 ：） > > > > > > > > > > > > > > >
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 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 wrote: > > > Hi Zhenghua, > > > > 感谢您的回复。感觉既然 Flink 已经提供了时区的设定，这方面也许可以进一步增强一些。CONVERT_TZ > > 用户很容易忘记或者漏掉，这里还是有不少完善的空间。 > > > > Best, > > Weike > > > > On Tue, Mar 24, 2020 at 4:20 PM Zhenghua Gao 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 > > > 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 的内置函数，社区是否会更容易接受一些呢？ > > > > > > > > 仅仅是个人一点想法，感谢 ：） > > > > > > > > > >
Re: 关于 SQL DATE_FORMAT 的时区设置的构想
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 wrote: > Hi Zhenghua, > > 感谢您的回复。感觉既然 Flink 已经提供了时区的设定，这方面也许可以进一步增强一些。CONVERT_TZ > 用户很容易忘记或者漏掉，这里还是有不少完善的空间。 > > Best, > Weike > > On Tue, Mar 24, 2020 at 4:20 PM Zhenghua Gao 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 > > 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 的内置函数，社区是否会更容易接受一些呢？ > > > > > > 仅仅是个人一点想法，感谢 ：） > > > > > >
Re: 关于 SQL DATE_FORMAT 的时区设置的构想
Hi Zhenghua, 感谢您的回复。感觉既然 Flink 已经提供了时区的设定，这方面也许可以进一步增强一些。CONVERT_TZ 用户很容易忘记或者漏掉，这里还是有不少完善的空间。 Best, Weike On Tue, Mar 24, 2020 at 4:20 PM Zhenghua Gao 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 > 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 的内置函数，社区是否会更容易接受一些呢？ > > > > 仅仅是个人一点想法，感谢 ：） > > >
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 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 的内置函数，社区是否会更容易接受一些呢？ > > 仅仅是个人一点想法，感谢 ：） >
关于 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 的内置函数，社区是否会更容易接受一些呢？ 仅仅是个人一点想法，感谢 ：）
