[
https://issues.apache.org/jira/browse/FINERACT-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17220395#comment-17220395
]
Michael Vorburger commented on FINERACT-826:
--------------------------------------------
Merging the PR for this issue caused FINERACT-1242 - will you help fix that?
> Migrate to java.time from 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
> Labels: technical
> Fix For: 1.5.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)
