SEPURI-SAI-KRISHNA commented on issue #12825:
URL: https://github.com/apache/seatunnel/issues/12825#issuecomment-6229210479
Thanks @DanielLeens. The focused PR is #12826, opened 2026-10-16 05:18 UTC
and linked from its description, but linking it explicitly here as you asked.
Noting that you approved it since, so the test change below is me meeting the
requirement you set here rather than a blocker you left open; it invalidates
that approval and costs another CI cycle, which seemed the right trade for the
coverage you asked for.
Taking your points in order.
**At the encoding boundary, not process wide.** One argument on the helper
`Calendar` inside the INT96 branch of `ParquetWriteStrategy`. No process locale
is set. `ParquetReadStrategy` is untouched; it decodes INT96 with plain
arithmetic and no `Calendar`.
**On "explicitly Gregorian".** The fix passes `Locale.ROOT`, which selects
`GregorianCalendar`, so `YEAR`, `MONTH` and `DAY_OF_MONTH` are Gregorian again.
If you would rather see `new GregorianCalendar(TimeZone.getTimeZone("UTC"))` or
a pure `java.time` conversion that removes `Calendar` from this path entirely,
say so and I will change it; the second is a slightly larger diff but arguably
the better end state, since it would remove the failure mode rather than
configure around it.
**The second calendar system.** You were right that one non-Gregorian locale
was not enough. The test now covers three default locales, asserting the value
and the time of day separately for each:
| default locale | calendar system | `get(YEAR)` for 2024 |
| --- | --- | --- |
| `en_US` | `GregorianCalendar` | 2024 |
| `th_TH` | `BuddhistCalendar` | 2567 |
| `ja-JP-u-ca-japanese` | `JapaneseImperialCalendar` | 6 |
It restores the previous default locale in a `finally`.
Both non-Gregorian cases were checked to fail on their own, by neutralising
the other assertion, so neither is carried by the other:
```
th_TH expected: <2024-03-15T13:45:30> but was:
<2567-03-15T13:45:30>
ja-JP-u-ca-japanese expected: <2024-03-15T13:45:30> but was:
<0006-03-17T13:45:30>
```
The Japanese case moves the day as well as the year, because the julian day
conversion lands differently at that era. That is a second failure shape rather
than a repeat of the Thai one, which is the value in your request.
**Scope kept narrow.** No broad `Calendar` changes elsewhere. Your reading
on the PR matches mine: the other `Calendar.getInstance` uses in
`seatunnel-connectors-v2` hand the calendar to `ResultSet.getTimestamp(...)`,
which never reads `get(YEAR)`, so they are not the same defect.
--
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]
