NIFI-9458 Replace SimpleDateFormat with DateTimeFormatter

[exceptionfactory]

Summary

NIFI-9458 Replaces direct use of java.text.SimpleDateFormat with java.time.format.DateTimeFormatter across component utilities and test classes.

SimpleDateFormat handles parsing and formatting instances of java.util.Date but it lacks features such as nanosecond precision, and can be subject to subtle conversion issues with time zone offsets.

DateTimeFormatter provides parsing and formatting for newer java.time classes, which provide greater precision than other types like java.sql.Time and java.sql.Timestamp.

Pattern characters for DateTimeFormatter are largely similar to SimpleDateFormat, with several additional characters supporting nanoseconds and optional boundaries. Some formatting patterns are more strict, which could lead to parsing failures on some existing custom formats. This is a primary reason for including these changes as part of the NiFi 2.0 release version.

Functional changes include removing date and time handling methods from the DataTypeUtils class and adding new FieldConverter implementations in the same nifi-record module. The new StandardFieldConverterRegistry provides an abstraction for retrieving registered instances of FieldConverter based on the expected output field type. The FieldConverter interface approach provides a more maintainable and focused approach to object conversion while the FieldConverterRegistry provides a similar level of reference convenience. Instances of DateTimeFormatter are thread-safe, unlike SimpleDateFormat, which enables instance caching inside the StandardFieldConverterRegistry.

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 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 mvn clean install -P contrib-check
  • JDK 21

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

[markobean]

@exceptionfactory
I took a quick "high level" peek at this. There are lot of changed files, but I searched for any which might have been missed inadvertently. I found instances of SimpleDateFormat usage in the following:

./nifi-nar-bundles/nifi-mongodb-bundle/nifi-mongodb-processors/src/main/java/org/apache/nifi/processors/mongodb/AbstractMongoProcessor.java
./nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/ParseCEF.java

[exceptionfactory]

@exceptionfactory I took a quick "high level" peek at this. There are lot of changed files, but I searched for any which might have been missed inadvertently. I found instances of SimpleDateFormat usage in the following:

./nifi-nar-bundles/nifi-mongodb-bundle/nifi-mongodb-processors/src/main/java/org/apache/nifi/processors/mongodb/AbstractMongoProcessor.java
./nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/ParseCEF.java

Thanks for pointing out those specific examples @markobean.

Those are the two remaining direct references to SimpleDateFormat because both components make direct use of the Jackson ObjectMapper, which requires an instance of DateFormat to drive formatting. Unfortunately those references cannot be changed. The key changes from a NiFi usage perspective are in nifi-record and nifi-record-path, where first-class use of SimpleDateFormat has been changed. There are many other changes in test classes, and the primary motivation for those changes was to provide better baseline examples for future development.

[bbende]

Looks good, nice refactoring isolating some of the conversion logic out of DataTypeUtils, will merge