Eyad-Sharkawy commented on PR #6714: URL: https://github.com/apache/fineract/pull/6714#issuecomment-6540153157
Hi @galovics, Thanks for the great catch and suggestions! 1. **`c.getLocalDateTimeCellValue().toLocalDate()`**: That's so much cleaner. Using POI 5's `getLocalDateTimeCellValue().toLocalDate()` eliminates `java.util.Date`, `getTenantOrSystemZoneId()`, and avoids any time zone shift issues between JVM and tenant zones. 2. **Dead formula evaluation branch in `readAsDate`**: You're completely right. Once `NUMERIC`, `STRING`, `BLANK`, and `ERROR` cached types are handled, the only remaining cached type is `BOOLEAN`, which cannot be a valid date anyway. I've removed that fallback branch along with `isDate1904`, `Date1904Support`, and the `HSSFWorkbook` imports. 3. **`readAsLong` and `readAsInt` parsing**: Reverted to `Long.parseLong` and `Integer.parseInt` (with safe blank handling) so decimals like `"12.7"` in ID columns fail fast rather than silently truncating or losing precision. 4. **Scope of PR & handlers**: I agree 100%. Keeping this PR focused strictly on fixing the formula cell evaluation in `ImportHandlerUtils` (as described in FINERACT-1283) is much cleaner. I created [FINERACT-3026](https://issues.apache.org/jira/browse/FINERACT-3026) to track passing `dateFormat`/`locale` and implementing row-level error reporting consistently across all ~17 import handlers. I have removed the handler changes from this PR. I will push the updated commit shortly! -- 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]
