Incorrectly parsed time string literal when "now()" is also in the insert sql

What type of bug is this?

Incorrect result

What subsystems are affected?

Query Engine

Minimal reproduce step

Start GreptimeDB with GREPTIMEDB_STANDALONE__DEFAULT_TIMEZONE=Asia/Shanghai, then:

mysql> select timezone();
+---------------+
| timezone()    |
+---------------+
| Asia/Shanghai |
+---------------+
1 row in set (0.00 sec)

mysql> create table foo (ts timestamp time index, st timestamp);
Query OK, 0 rows affected (0.01 sec)

mysql> insert into foo (ts) values ('2026-08-01 12:00:00.001');
Query OK, 1 row affected (0.00 sec)

mysql> insert into foo (ts, st) values ('2026-08-02 12:00:00.001', now());
Query OK, 1 row affected (0.00 sec)

mysql> insert into foo (ts, st) values ('2026-08-03 12:00:00.001', '2026-08-12 14:00:00.001');
Query OK, 1 row affected (0.01 sec)

mysql> select * from foo order by ts;
+-------------------------+-------------------------+
| ts                      | st                      |
+-------------------------+-------------------------+
| 2026-08-01 12:00:00.001 | NULL                    |
| 2026-08-02 20:00:00.001 | 2026-08-12 15:07:00.717 |
| 2026-08-03 12:00:00.001 | 2026-08-12 14:00:00.001 |
+-------------------------+-------------------------+
3 rows in set (0.00 sec)

Note that the second insert uses "now()", then the query result of "ts" is wrong. Clearly the "ts" is parsed as UTC timezone instead of UTC+8(Asia/Shanghai) timezone.

What did you expect to see?

now() does not affect other time string literals' parsing

What did you see instead?

the opposite

What operating system did you use?

ubuntu

What version of GreptimeDB did you use?

greptime-registry.cn-hangzhou.cr.aliyuncs.com/greptime/greptimedb-nightly:nightly-20260812-943eee852

Relevant log output and stack trace