NIFI-15973 Fix issues caused by the use of deprecated GregorianCalendar by Kamilkime · Pull Request #11283 · apache/nifi

Kamilkime · 2026-05-25T16:29:34Z

Summary

Avoid Julian-calendar shift when converting java.sql.Date / java.sql.Timestamp values to java.time types (and back) in NiFi's record framework.

java.sql.Timestamp#toLocalDateTime, java.sql.Timestamp#valueOf(LocalDateTime), java.sql.Date#toLocalDate, and java.sql.Date#valueOf(LocalDate) all route through GregorianCalendar, which applies Julian-calendar semantics for years before 1582-10-15. As a result, a value whose epoch milliseconds represent year 0001 in the proleptic Gregorian calendar (the calendar java.time, Avro, BigQuery, or Snowflake all use) is rendered as year 0000 — about a 2-day backward shift. Downstream sinks that validate against an inclusive year-1-to-9999 range (e.g., the Snowflake Ingest SDK) then reject the row: Timestamp out of representable inclusive range of years between 1 and 9999, ... value:0000-12-30T10:47Z.

The fix replaces every Julian-aware bridge between java.sql.* and java.time.* with an Instant-based one, which preserves the proleptic-Gregorian instant the source actually carried.

Tests:

ObjectLocalDateFieldConverterTest (new): null input, LocalDate passthrough, java.sql.Date modern-year round-trip, and a year-0001 java.sql.Date regression test that asserts the result is year 0001 (not year 0000).
TestObjectLocalDateTimeFieldConverter: add testConvertTimestampYearOneIsProlepticGregorian (year-0001 Timestamp round-trip) and testConvertStringYearOneIsProlepticGregorian (year-0001 string parsed via formatter).
ObjectTimestampFieldConverterTest: add testConvertFieldStringYearOneIsProlepticGregorian and testConvertFieldLocalDateTimeYearOneIsProlepticGregorian to lock in the year-0001 result for both string and LocalDateTime inputs.
ObjectStringFieldConverterTest: add testConvertFieldTimestampYearOneIsProlepticGregorian covering the formatted-output path.
New regression tests fail on main and pass on this branch.

Compatibility:

Backwards compatible. Instant-based conversion and Julian-aware Timestamp / Date conversion agree for every date from 1582-10-15 onward, so all values produced after the Gregorian cutover (i.e., everything the vast majority of users have ever ingested) are unchanged. Pre-cutover values — including the 1582-10-05 → 1582-10-14 gap that Julian had but proleptic Gregorian does not — now match the proleptic-Gregorian instant the source actually carried, which is what java.time, Avro, and downstream sinks already assume.

No public API signatures change, the fix is purely internal to the existing converter implementations.

Tracking

Please complete the following tracking steps prior to pull request creation.

Issue Tracking

Apache NiFi Jira issue created

Pull Request Tracking

Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000
Pull request contains commits signed with a registered key indicating Verified status

Pull Request Formatting

Pull Request based on current revision of the main branch
Pull Request refers to a feature branch with one commit containing changes

Verification

Please indicate the verification steps performed prior to pull request creation.

Build

Build completed using ./mvnw clean install -P contrib-check
- JDK 21
- JDK 25

Licensing

New dependencies are compatible with the Apache License 2.0 according to the License Policy
New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

Documentation formatting appears as expected in rendered files

exceptionfactory

Thanks for describing the issues with the current Date and Timestamp conversion @Kamilkime. This pull request highlights the subtle behavior of different time classes.

I noted some recommendations related to the unit test methods for readability and clear construction.

Regarding the functional change, it appears reasonable from one perspective, since date conversion of all modern values are unchanged. I would expect this to cover many use cases without concern.

The key question is whether the change in behavior for ancient dates is acceptable. At minimum, the nuance should be commented in the Converter classes that the described approach uses the Proleptic Gregorian Calendar System, avoid the implicit use of deprecated Date conversion methods. Declaring the intermediate values would also helpful emphasize the behavioral adjustment.

exceptionfactory · 2026-05-25T20:21:24Z

+        final Instant expected = LocalDateTime.of(1, 1, 1, 12, 0, 0).atZone(ZoneId.systemDefault()).toInstant();
+        assertEquals(expected, timestamp.toInstant());


Unit tests should assert expected Timestamp values, not values converted to Instant objects.

Changed to Timestamp assertions

exceptionfactory · 2026-05-25T20:22:05Z

+    @Test
+    public void testConvertStringYearOneIsProlepticGregorian() {
+        final LocalDateTime result = converter.convertField("0001-01-01 12:00:00", Optional.of("yyyy-MM-dd HH:mm:ss"), FIELD_NAME);
+        assertEquals(LocalDateTime.of(1, 1, 1, 12, 0, 0), result);


The expected value should be declared separately instead of inline instance creation for clarity.

Extracted expected variable

exceptionfactory · 2026-05-25T20:23:42Z

+                    final LocalDate localDate = (value instanceof LocalDate ld) ? ld : LocalDate.ofEpochDay((int) value);
+                    return new java.sql.Date(localDate.atStartOfDay(ZoneId.systemDefault()).toInstant().toEpochMilli());


The inline ternary and cast is difficult to read, and the multiple levels of conversion to create the new java.sql.Date() should be split out and declared.

Used an if statement for the localDate value, and extracted zonedDate

exceptionfactory · 2026-05-25T20:27:31Z

+    @Test
+    void testConvertFieldSqlDateModernYear() {
+        final LocalDate localDate = LocalDate.of(2025, 5, 25);
+        final Date sqlDate = new Date(localDate.atStartOfDay(ZoneId.systemDefault()).toInstant().toEpochMilli());


Intermediate values should be declared for readability.

Extracted zonedDate

Kamilkime

Thanks @exceptionfactory, I addressed your comments, please let me know if it looks good now

Kamilkime · 2026-05-26T11:17:20Z

+    @Test
+    void testConvertFieldSqlDateModernYear() {
+        final LocalDate localDate = LocalDate.of(2025, 5, 25);
+        final Date sqlDate = new Date(localDate.atStartOfDay(ZoneId.systemDefault()).toInstant().toEpochMilli());


Extracted zonedDate

Kamilkime · 2026-05-26T11:27:36Z

+    @Test
+    public void testConvertStringYearOneIsProlepticGregorian() {
+        final LocalDateTime result = converter.convertField("0001-01-01 12:00:00", Optional.of("yyyy-MM-dd HH:mm:ss"), FIELD_NAME);
+        assertEquals(LocalDateTime.of(1, 1, 1, 12, 0, 0), result);


Extracted expected variable

Kamilkime · 2026-05-26T11:36:22Z

+                    final LocalDate localDate = (value instanceof LocalDate ld) ? ld : LocalDate.ofEpochDay((int) value);
+                    return new java.sql.Date(localDate.atStartOfDay(ZoneId.systemDefault()).toInstant().toEpochMilli());


Used an if statement for the localDate value, and extracted zonedDate

Kamilkime · 2026-05-26T11:48:11Z

+        final Instant expected = LocalDateTime.of(1, 1, 1, 12, 0, 0).atZone(ZoneId.systemDefault()).toInstant();
+        assertEquals(expected, timestamp.toInstant());


Changed to Timestamp assertions

Kamilkime added 2 commits May 25, 2026 18:58

NIFI-15973 Fix issues caused by the use of deprecated GregorianCalendar

cd7d144

NIFI-15973 Remove comments

d7a238f

Kamilkime force-pushed the kamilkime/NIFI-15973-julian-calendar-fix branch from 2592587 to d7a238f Compare May 25, 2026 17:00

Kamilkime marked this pull request as ready for review May 25, 2026 17:01

exceptionfactory requested changes May 25, 2026

View reviewed changes

NIFI-15973 Address review comments

f00faa8

Kamilkime commented May 26, 2026

View reviewed changes

Kamilkime requested a review from exceptionfactory May 26, 2026 11:53

NIFI-15973 Import sql.Date, remove unused import

22174a9

		final Instant expected = LocalDateTime.of(1, 1, 1, 12, 0, 0).atZone(ZoneId.systemDefault()).toInstant();
		assertEquals(expected, timestamp.toInstant());

		final LocalDate localDate = (value instanceof LocalDate ld) ? ld : LocalDate.ofEpochDay((int) value);
		return new java.sql.Date(localDate.atStartOfDay(ZoneId.systemDefault()).toInstant().toEpochMilli());

Conversation

Kamilkime commented May 25, 2026

Summary

Tracking

Issue Tracking

Pull Request Tracking

Pull Request Formatting

Verification

Build

Licensing

Documentation

Uh oh!

exceptionfactory left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Kamilkime left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants