[
https://issues.apache.org/jira/browse/FINERACT-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098594#comment-17098594
]
Michael Vorburger commented on FINERACT-826:
--------------------------------------------
FTR: If we do want to (start to) adopt {{java.time}} instead (ultimately, and
while transitioning possibly in parallel; or is a "bang bang" perhaps easier
and better, here?) we need to register respective
{{com.google.gson.JsonSerializer}}; FINERACT-926 has a related PR which will be
useful here.
> org.apache.fineract.infrastructure.core.service.DateUtils has un-used line,
> and should use java.time instead of Joda API
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: FINERACT-826
> URL: https://issues.apache.org/jira/browse/FINERACT-826
> Project: Apache Fineract
> Issue Type: Bug
> Affects Versions: 1.4.0
> Reporter: Michael Vorburger
> Assignee: Percy Ashu
> Priority: Major
> Fix For: 1.4.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> [http://mail-archives.apache.org/mod_mbox/fineract-dev/201907.mbox/%3ccalix4ib1d32zskzn87kureosbwscjmo9dhgnoqbwydyui-c...@mail.gmail.com%3e,]
> and the original previous and the follow up replies on that thread Subject
> "Questions about my approach to find problems with tenant time zones, and
> about the instance values of SQL migration files.", related to FINERACT-723?
> I think, point out that
> {{org.apache.fineract.infrastructure.core.service.DateUtils}} could do with a
> closer look and fixes, specifically:
> {quote}That DateUtils class is interesting.. do we really need to mix the old
> java.util.Date API and the org.joda.time Time API ? FYI Joda Time has been
> integrated into Java 8 as java.time. So if someone was up for taking up work
> related to cleaning that up, that could be useful IMHO (so converge
> everything to java.time, and eventually remove the Joda dependency, and
> introduce an enforced check via Checkstle or SpotBugs to forbid
> java.util.Date).
>
> The null management in DateUtils is pretty interesting as well. So is this
> per tenant TZ guaranteed to always be in the DB? What does the DB schema say
> - required, never NULL? Does the Java code ensure it's never null? I'm asking
> these questions because something like that getLocalDateTimeOfTenant(),
> despite its name, seems to be actually be written to EITHER give us a "local"
> time based on the tenant, or, if that's null, it just falls back to what l
> suspect (not verified) is dependent on the OS / JVM TZ - that's scary.
> Perhaps it's not a problem in reality, if every tenant is guaranteed to
> always have a TZ, but if someone could double check this, and if so remove
> those null check and system dependent fallbacks, then IMHO that would make
> that utility code clearer.
>
> BTW line 45 in DateUtils seems completely useless, agreed? Would you like to
> raise a PR proposing to ditch that?
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
