Cannot apply ‘TO_TIMESTAMP‘ to arguments of type ‘TO_TIMESTAMP(<BIGINT>)‘. Supported form(s)

前言

我是使用flink table api 出现的错误,我使用的版本是 1.13.1.
这个错出现真的很奇怪,阿里云官网是支持的,blink 的 时间函数已经说明
TO_TIMESTAMP 这个支持 时间戳(毫秒),或者字符串。
但实际中却不可以用。真的很。。。

在这里插入图片描述

阿里云官网

我的sql 写法:

data_time 是 13位时间戳,但是不可以。

public static final String SOURCE_KAFKA_SNAPSHOT = "CREATE TABLE  tableName (\n" +
            "`date_time` BIGINT ,\n" +
            "`hs_security_id` VARCHAR ,\n" +
            "`security_id` VARCHAR ,\n" +
            "`num_trades` DECIMAL,\n" +
            "`volume` BIGINT,\n" +
            "`amount` DECIMAL,\n" +
            "`phase_code` BIGINT,\n" +
            "bid_price VARCHAR,\n" +
            "bid_qty VARCHAR,\n" +
            "ts AS TO_TIMESTAMP(date_time)," +
            " WATERMARK FOR ts AS ts - INTERVAL '10' SECOND \n" +
            ")WITH (\n" +
            "  'connector' = 'kafka', \n" +
            "  'topic'='xxx',\n" +
            "  'properties.bootstrap.servers' = 'xxx.xxx.xx.xx:9092', \n" +
            "  'format' = 'json',\n" +
            "  'scan.startup.mode' = 'earliest-offset',\n" +
            "'json.fail-on-missing-field' = 'false',\n" +
            " 'json.ignore-parse-errors' = 'true'" +
            ")";

报错信息如下:

Exception in thread "main" org.apache.calcite.runtime.CalciteContextException: From line 18, column 7 to line 18, column 29: Cannot apply 'TO_TIMESTAMP' to arguments of type 'TO_TIMESTAMP(<BIGINT>)'. Supported form(s): 'TO_TIMESTAMP(<CHARACTER>)'
'TO_TIMESTAMP(<CHARACTER>, <CHARACTER>)'
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:467)
	at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:883)
	at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:868)
	at org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4861)
	at org.apache.calcite.sql.SqlCallBinding.newValidationSignatureError(SqlCallBinding.java:389)
	at org.apache.calcite.sql.type.FamilyOperandTypeChecker.checkSingleOperandType(FamilyOperandTypeChecker.java:106)
	at org.apache.calcite.sql.type.FamilyOperandTypeChecker.checkOperandTypes(FamilyOperandTypeChecker.java:140)
	at org.apache.calcite.sql.type.CompositeOperandTypeChecker.checkOperandTypes(CompositeOperandTypeChecker.java:256)
	at org.apache.calcite.sql.SqlOperator.checkOperandTypes(SqlOperator.java:679)
	at org.apache.calcite.sql.SqlOperator.validateOperands(SqlOperator.java:444)
	at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:330)
	at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:226)
	at org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5710)
	at org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5697)
	at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:139)
	at org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1736)
	at org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1727)
	at org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:956)
	at org.apache.calcite.sql.validate.SqlValidatorImpl.validateParameterizedExpression(SqlValidatorImpl.java:941)
	at org.apache.flink.table.planner.operations.MergeTableLikeUtil$SchemaBuilder.appendDerivedColumns(MergeTableLikeUtil.java:434)
	at org.apache.flink.table.planner.operations.MergeTableLikeUtil$SchemaBuilder.access$000(MergeTableLikeUtil.java:209)
	at org.apache.flink.table.planner.operations.MergeTableLikeUtil.mergeTables(MergeTableLikeUtil.java:150)
	at org.apache.flink.table.planner.operations.SqlCreateTableConverter.createCatalogTable(SqlCreateTableConverter.java:117)
	at org.apache.flink.table.planner.operations.SqlCreateTableConverter.convertCreateTable(SqlCreateTableConverter.java:70)
	at org.apache.flink.table.planner.operations.SqlToOperationConverter.convert(SqlToOperationConverter.java:238)
	at org.apache.flink.table.planner.delegation.ParserImpl.parse(ParserImpl.java:101)
	at org.apache.flink.table.api.internal.TableEnvironmentImpl.executeSql(TableEnvironmentImpl.java:724)

解决办法

对与 13位时间戳要这样

SELECT TO_TIMESTAMP(FROM_UNIXTIME(1513135677000 / 1000, 'yyyy-MM-dd HH:mm:ss'))
SQL Query Result (Table)   2017-12-13T11:27:57

我又测试字符串时间 发现 TO_TIMESTAMP可以支持CHARACTER类型表示的datetime数据例如2017-12-13 11:27:57。

SELECT TO_TIMESTAMP('2017-12-13 11:27:57', 'yyyy-MM-dd HH:mm:ss'))
SQL Query Result (Table)   2017-12-13T11:27:57

<think>嗯,用户问的是to_unix_timestamp和unix_timestamp之间的区别。我需要先弄清楚这两个函数在不同系统里的表现。根据提供的引用,比如引用[3]提到spark-sql中使用to_unix_timestamp将字符串转为时间戳,而引用[2]里说unix_timestamp可以不带参数返回当前时间戳,或者带日期参数转换。 可能要注意的是,不同数据库或处理框架中的实现可能不同。比如在Hive或MySQL中,unix_timestamp可能作为函数名,而Spark SQL中可能用to_unix_timestamp来明确转换。需要区分它们的参数格式是否必须指定,以及返回值类型是否有差异。 引用[4]提到to_timestamp和from_unixtime的使用,涉及到类型转换,比如biginttimestamp可能需要用FROM_UNIXTIME。这可能影响到用户在处理时间戳时是否需要调整格式。 另外,用户可能需要了解语法差异,比如unix_timestamp在Spark中是否需要指定格式,而to_unix_timestamp是否强制要求格式参数。例如,引用[3]中的例子显示to_unix_timestamp需要指定格式,而引用[2]中的unix_timestamp可能支持更多隐式格式。 还要考虑返回值的单位,是否是秒还是毫秒,比如引用[4]提到bigint类型为13位毫秒,需要除以1000,这可能涉及到函数处理时间戳时的精度问题。 总结下来,区别主要在于函数名在不同系统中的使用、参数要求(是否必须指定格式)、以及是否支持隐式转换。需要明确回答这两个函数的功能、参数差异和适用场景,帮助用户正确选择使用哪一个。</think>### 功能及区别分析 **`unix_timestamp`** 和 **`to_unix_timestamp`** 均为时间戳转换函数,但使用场景和语法细节存在差异: #### 1. **功能定义** - **`unix_timestamp`** - **无参数调用**:返回当前时间的Unix时间戳(以秒为单位),例如: $$ \text{SELECT UNIX_TIMESTAMP()} → 1717023000 \quad (\text{当前时间对应的秒数}) $$ [^2] - **带参数调用**:将指定格式的日期字符串转换为Unix时间戳,支持隐式格式解析,例如: $$ \text{SELECT UNIX_TIMESTAMP('2023-01-20 10:00:00')} → 1674180000 $$ [^2] - **`to_unix_timestamp`** - **必须带参数调用**:**强制要求指定日期字符串和格式**,将字符串按给定格式转换为Unix时间戳,例如: $$ \text{SELECT TO_UNIX_TIMESTAMP('20231021', 'yyyyMMdd')} → 1697846400 $$ [^3] #### 2. **核心区别** | 特性 | `unix_timestamp` | `to_unix_timestamp` | |--------------------|--------------------------|-----------------------------| | **参数要求** | 可无参数,可接受隐式日期格式 | 必须指定日期字符串和格式 | | **格式灵活性** | 支持多种隐式日期格式(如`yyyy-MM-dd`) | 需严格匹配指定格式(如`yyyyMMdd`) | | **典型应用场景** | 简单转换或获取当前时间戳 | 需要明确控制输入格式的场景 | #### 3. **实际案例对比** - **隐式转换 vs 显式转换** ```sql -- 隐式解析(unix_timestamp) SELECT UNIX_TIMESTAMP('2023-01-20'); -- 自动解析为日期 -- 显式解析(to_unix_timestamp) SELECT TO_UNIX_TIMESTAMP('20230120', 'yyyyMMdd'); -- 必须指定格式 ``` 若日期格式不标准(如`20230120`),`unix_timestamp`可能解析失败,而`to_unix_timestamp`通过指定格式可确保转换成功[^3][^4]。 - **与`from_unixtime`联动** ```sql -- 时间戳转字符串 SELECT FROM_UNIXTIME(1674180000, 'yyyy-MM-dd HH:mm:ss') → '2023-01-20 10:00:00' [^3] ``` #### 4. **注意事项** - **类型兼容性**:若原始时间为`BIGINT`类型(如13位毫秒时间戳),需先转换为秒: $$ \text{TO_TIMESTAMP}(ts/1000) \quad \text{或} \quad \text{FROM_UNIXTIME}(ts/1000) $$ [^4] - **时区影响**:两者默认使用系统时区,跨时区场景需显式指定。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值