bug(batch): Do not try to write %#z it is undefined

[kwannoel]

Describe the bug

SELECT ((1) - (718)) AS col_0, (to_char((DATE '2022-01-12' - (~ (INT '140'))), t_0.name)) AS col_1, (BIGINT '975') AS col_2, t_0.id AS col_3 FROM person AS t_0 FULL JOIN m3 AS t_1 ON t_0.extra = t_1.col_2 AND true WHERE true GROUP BY t_0.name, t_0.id HAVING true
thread '<unnamed>' panicked at 'Do not try to write %#z it is undefined', /risingwave/.cargo/registry/src/index.crates.io-6f17d22bba15001f/chrono-0.4.24/src/format/mod.rs:679:25

Error message/log

No response

To Reproduce

No response

Expected behavior

No response

How did you deploy RisingWave?

No response

The version of RisingWave

No response

Additional context

No response

[kwannoel]

Repro: select to_char(DATE '2022-01-12' - (~ (INT '140')), '%#z');

[kwannoel]

Seems like a bug with the underlying library.. Continue looking at it next week.

[xiangjinwu]

https://docs.rs/chrono/0.4.26/chrono/format/strftime/index.html

• %#z is documented as Parsing only and should not be used in to_char implementation
• %:::z is documented to be Offset from the local time to UTC without minutes which aligns with PostgreSQL TZH. However, its implementation in parsing is wrong Flexible offset parsing [2/3] chronotope/chrono#1083

Once chrono fixed the issue, we can just map TZH to %:::z. If we need a fix before that, we will need to map TZH to %:::z in to_char but to %#z during parsing.

[github-actions]

This issue has been open for 60 days with no activity.

If you think it is still relevant today, and needs to be done in the near future, you can comment to update the status, or just manually remove the no-issue-activity label.

You can also confidently close this issue as not planned to keep our backlog clean.
Don't worry if you think the issue is still valuable to continue in the future.
It's searchable and can be reopened when it's time. 😄