SEPURI-SAI-KRISHNA opened a new issue, #12825: URL: https://github.com/apache/seatunnel/issues/12825
### Search before asking - [X] I had searched in the [issues](https://github.com/apache/seatunnel/issues?q=is%3Aissue+label%3A%22bug%22) and found no similar issues. ### What happened With `parquet_avro_write_timestamp_as_int96 = true`, the file sink writes INT96 timestamps that are **543 years in the future** when the JVM default locale is Thai. The file on disk is permanently wrong, and nothing fails or warns. `ParquetWriteStrategy.java:265` builds the INT96 value through `java.util.Calendar`: ```java Calendar calendar = Calendar.getInstance(TimeZone.getTimeZone("UTC")); calendar.setTime(Date.from(localDateTime.atZone(ZoneId.systemDefault()).toInstant())); int julianDays = (int) JulianFields.JULIAN_DAY.getFrom( LocalDate.of(calendar.get(Calendar.YEAR), calendar.get(Calendar.MONTH) + 1, calendar.get(Calendar.DAY_OF_MONTH))); ``` `Calendar.getInstance(TimeZone)` consults the default **locale** as well as the time zone, and the locale selects the calendar system. Under a Thai default locale it returns a `BuddhistCalendar`, so `get(Calendar.YEAR)` is the Buddhist year. That value is then passed to `LocalDate.of(...)` as if it were Gregorian. ### Measured Input `2024-03-15T13:45:30`, expected Gregorian `YEAR=2024`, on OpenJDK 17.0.20: | default locale | calendar returned | `get(YEAR)` | julianDay | | --- | --- | --- | --- | | `en_US` | `GregorianCalendar` | 2024 | 2460385 | | `th_TH` | `BuddhistCalendar` | **2567** | **2658711** | | `ja_JP` | `GregorianCalendar` | 2024 | 2460385 | | `ja-JP-u-ca-japanese` | `JapaneseImperialCalendar` | **6** | 1723325 | | `ar_SA` | `GregorianCalendar` | 2024 | 2460385 | Plain `th_TH` is enough. No `-u-ca-buddhist` extension is needed, so an OS locale or `-Duser.language=th -Duser.country=TH` is sufficient. ### Reproduced end to end on `dev` Writing one row through `ParquetWriteStrategy` and reading it back through `ParquetReadStrategy`: ``` value written : 2024-03-15T13:45:30 read back (en_US) : 2024-03-15T13:45:30 read back (th_TH) : 2567-03-15T13:45:30 ``` ### Why no test catches it `ParquetWriteStrategyTest#testParquetWriteInt96` and `#testParquetWriteInt96WithMixedCaseTimestampColumn` assert the parquet **schema types** (INT96 vs BINARY). They write `LocalDateTime.now()` and never compare a round-tripped value, so a wrong timestamp passes both. ### What you expected to happen A timestamp written as INT96 reads back as the same instant regardless of the JVM default locale. The calendar system used for an on-disk format should not depend on the operating system locale of whichever machine runs the job. ### SeaTunnel Version `dev` (verified against the live file at `?ref=dev`; the line is unchanged). ### Note This is a different defect from the INT96 field-name casing issues (#11928, #10943, #10928), which touch the same area. The general question of locale-dependent APIs such as `Calendar.getInstance` is already raised as question 3 on #12620; this issue is only the one proven Parquet case. ### Are you willing to submit PR? - [X] Yes I am willing to submit a PR! ### Code of Conduct - [X] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
