[C++] Reader cannot resolve Java fixed-offset writer timezone IDs such as GMT-00:00
还没有人认领这个 Issue。
评估
- 难度
- 3/5
- 预计耗时
- 1-2 天
- 新手友好度
- 68/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
调研方向
Start with c++/src/Timezone.cc, especially getTimezoneByName and getTimezoneByFilename, then run orc-contents against the supplied gmt-0000.orc fixture. Confirm that the reader accepts the GMT-00:00 writerTimezone and still handles normal zoneinfo names correctly.
由索引模型根据 Issue 内容生成。
描述
I was closing out some old Arrow issues and this one (apache/arrow#21471, from 2019) looks like it is potentially an ORC bug rather than an Arrow one. I don't understand this domain well myself, so everything below the line was produced by Claude working through the ORC and Arrow source with me. I have checked that the reprex fails against current main (4dbfe288) as described, but I have not independently verified the code reading, so please treat it accordingly. I have tried to keep it concise.
Cause
When the JVM's default zone is a fixed offset, the Java writer records a custom ID such as GMT-00:00 or GMT+05:30 as the stripe writerTimezone (WriterImpl.java:563 uses TimeZone.getDefault().getID()). The Java reader accepts these because TimeZone.getTimeZone parses GMT±hh:mm (TreeReaderFactory.java:1251).
The C++ reader resolves a writer timezone only by opening $TZDIR/<name> (getTimezoneByName in c++/src/Timezone.cc), plus the US/* alias map from ORC-2011. No such file exists for GMT-00:00, so any stripe with a timestamp column fails:
$ orc-contents gmt-0000.orc
Caught exception in gmt-0000.orc: Time zone file /usr/share/zoneinfo/GMT-00:00 does not exist. Please install IANA time zone database and set TZDIR env.
Adding a GMT-00:00 symlink to GMT under TZDIR makes the same file read fine, so the timezone name is the only problem with it.
Reprex
gmt-0000.orc (250 bytes) has one stripe, one timestamp column, uncompressed, with writerTimezone set to GMT-00:00. It was written with the C++ writer via pyorc (with TZDIR pointed at a directory containing a GMT-00:00 zone file) to reproduce the footer field that Hive produced in the original report.
gmt-0000.orc as base64 (decode with base64 -d)
T1JDCgYSBAgBUAAKHgoEAAAAABIWCAFKEBjA2u/vslogwNrv77JaMAFQAHYAD9kwyEAAAAoGCAYQABgICgYIBhABGCAKBggBEAEYBgoGCAUQARgDEgQIABAAEgQIAhAAGglHTVQtMDA6MDAKHgoECAFQAAoWCAFKEBjA2u/vslogwNrv77JaMAFQAAgDEGgaCggDECgYCSA3KAEiDwgMEgEBGgJ0cyAAKAAwACIICAkgACgAMAAwAToECAFQADoWCAFKEBjA2u/vslogwNrv77JaMAFQAECQTkgBYgUyLjEuNAhXEAAYgIAEIgIADCggMAaC9AMDT1JDFw==
Suggested fix (untested)
Recognise names matching GMT[+-]hh(:mm)? in getTimezoneByFilename and return a fixed-offset Timezone instead of loading a file. The Etc/GMT±n zoneinfo files are not a substitute since they only cover whole hours and use the inverted POSIX sign.
- 主要语言
- Java
- 星标
- 770
- 派生
- 515
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
apache/orc 的其他 Issue
-
estimateRgEndOffset slop calculation is insufficient for incompressible data可能已有人在做 @thexiay 于 174 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
-
cross compile未关闭
难度 4/5 3-5 天 新手友好度 35/100
-
难度 5/5 一周以上 新手友好度 20/100
相似的 Issue
-
bug web-server
难度 2/5 1-3 小时 新手友好度 78/100
jooby-project/jooby#4035 ·
维护者通常 1 天内回复
-
L: javascript
难度 2/5 1-3 小时 新手友好度 72/100
dependabot/dependabot-core#16744 ·
维护者通常 1 天内回复
-
intake mcp-intake needs-human-review priority:high type:bug
难度 2/5 1-3 小时 新手友好度 62/100
Ikalus1988/MisakaNet#3987 · 3 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
quarkiverse/quarkus-google-cloud-services#1187 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 82/100
locationtech/jts#1250 ·