Deprecating the use of older Java date formatting code

[Mike Thomsen <mi...@gmail.com>]

A new contributor raised some good questions on a PR:

https://github.com/apache/nifi/pull/7169

I rebased this branch as we discussed in the original PR, but I see that
meantime NiFi code become much more dependent on DateFormat. I see many
public methods in DataTypeUtils taking or returning DateFormat. I see some
transition methods like DateTypeUtils.getDateTimeFormatter. It makes me
feel that:


   - I don't see the wider picture of where you already use DateFormat now
      and how you planning to use it in the future
      - I don't know what is the plan to get rid of DateFormat because it
      looks like there is some
      - I don't know if you want to use a lenient, case insensitive format
      in all these places or some other one

If you want to draw me a wider picture I can try to continue this change
but otherwise, I don't want to introduce some ambiguous behaviour in date
format handling so I'll close this PR.


For NiFi 2.0, I think I would favor eliminating all pre-Java 8 Date/Time
API code and making it a blocker for new PRs to introduce functionality
that uses the old APIs. Thoughts?


Mike

Re: Deprecating the use of older Java date formatting code

[David Handermann <ex...@apache.org>]

Mike,

Thanks for bringing this up for discussion. One of the approved NiFi 2.0
Release Goals was upgrading internal Java API references [1] including
moving to java.time components over java.util.Date. Jira Epic NIFI-9458 [2]
is a general issue to cover this work.

With that as background, moving in this direction is definitely something
we need to do. I will note, however, that it will require more than just
swapping out specific methods in DataTypeUtils. When it comes to the impact
on JDBC and Avro integration, we need to be extremely careful where and how
we introduce the changes.

We have made progress in several areas, removing internal conversion to UTC
from implicitly local representations like java.sql.Date, but there is
still at least one conversion method that needs to be removed. With that in
mind, adding a new issue under the NIFI-9458 epic would be a good way to
outline a new approach.

I will comment on the pull request, and I think it works well as a targeted
change for Expression Language, then other issues can cover remaining
framework references.

Regards,
David Handermann

[1]
https://cwiki.apache.org/confluence/display/NIFI/NiFi+2.0+Release+Goals#NiFi2.0ReleaseGoals-UpgradeInternalJavaAPIReferences
[2] https://issues.apache.org/jira/browse/NIFI-9458

On Thu, Apr 20, 2023 at 4:28 PM Mike Thomsen <mi...@gmail.com> wrote:

> A new contributor raised some good questions on a PR:
>
> https://github.com/apache/nifi/pull/7169
>
> I rebased this branch as we discussed in the original PR, but I see that
> meantime NiFi code become much more dependent on DateFormat. I see many
> public methods in DataTypeUtils taking or returning DateFormat. I see some
> transition methods like DateTypeUtils.getDateTimeFormatter. It makes me
> feel that:
>
>
>    - I don't see the wider picture of where you already use DateFormat now
>       and how you planning to use it in the future
>       - I don't know what is the plan to get rid of DateFormat because it
>       looks like there is some
>       - I don't know if you want to use a lenient, case insensitive format
>       in all these places or some other one
>
> If you want to draw me a wider picture I can try to continue this change
> but otherwise, I don't want to introduce some ambiguous behaviour in date
> format handling so I'll close this PR.
>
>
> For NiFi 2.0, I think I would favor eliminating all pre-Java 8 Date/Time
> API code and making it a blocker for new PRs to introduce functionality
> that uses the old APIs. Thoughts?
>
>
> Mike
>