[
https://issues.apache.org/jira/browse/FINERACT-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17113456#comment-17113456
]
Petri Tuomola commented on FINERACT-723:
----------------------------------------
[~vorburger] - thanks.
After my PR, the current integration test scope seems to work as everything is
hardcoded to point to the same timezone (Asia/Kolkata).
A better solution would of course be to remove all the hardcoding (currently at
least in Travis script and in Utils class used for RestAssured tests).
However to make everything work with any timezone for
tenant/database/application server without any hardcoding would require finding
all the places that currently use application server or database date, and to
rewrite them to use the tenant date instead.
I'll unassign this so that anyone who wants to tackle the "full" solution can
pick this up.
> Integration tests fail when the default tenant has a different time-zone than
> the system(s) running the application and database servers
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: FINERACT-723
> URL: https://issues.apache.org/jira/browse/FINERACT-723
> Project: Apache Fineract
> Issue Type: Bug
> Affects Versions: 1.1.0, 1.2.0, 1.3.0
> Reporter: Vishwas Babu A J
> Assignee: Petri Tuomola
> Priority: Critical
> Labels: GSOC, GSoC, gsoc, gsoc2019, gsoc2020
> Fix For: 1.4.0
>
>
> Each tenant in Fineract has its timezone configured in the `tenants` table
> under the `fineractplatform-tenants` schema and the application should
> consider the same while carrying out any date/time related operations. This
> does not seem to be done consistently in the application and intermittent
> errors can be seen when the Application (tomcat) and database servers (MySQL)
> are run on systems with different timezones than that of the tenant.
> Ex: Set the System timezone to "PDT". The default demo tenant is set to
> "Asia/Kolkata" and integration tests run on the same would fail
> intermittently.
> Fixing the same would involve
> * Ensuring that all dates created in the API / service layers are done in a
> tenant sensitive fashion by utilizing the methods present in the class
> org.apache.fineract.infrastructure.core.service.DateUtils.
> * Ensure database operations do not use MySQL date functions. Ex:
> {code:java}
> @Override
> public Collection<SavingsAccountAnnualFeeData>
> retrieveChargesWithAnnualFeeDue() {
> final String sql = "select " + this.chargeDueMapper.schema() + "
> where sac.charge_due_date is not null and sac.charge_time_enum = ? "
> + " and sac.charge_due_date <= NOW() and sa.status_enum = ? ";
> return this.jdbcTemplate.query(sql, this.chargeDueMapper, new
> Object[] {ChargeTimeType.ANNUAL_FEE.getValue(),
> SavingsAccountStatusType.ACTIVE.getValue()});
> }{code}
> in
> org.apache.fineract.portfolio.savings.service.SavingsAccountChargeReadPlatformServiceImpl
> would cause issues with Timezones. We should be using something along the
> lines of
> {code:java}
> @Override
> public Collection<SavingsAccountAnnualFeeData>
> retrieveChargesWithAnnualFeeDue() {
> String currentdate = formatter.print(DateUtils.getLocalDateOfTenant());
> final String sql = "select " + this.chargeDueMapper.schema() + " where
> sac.charge_due_date is not null and sac.charge_time_enum = ? and
> sac.charge_due_date <= ? and sa.status_enum ? ";
>
> return this.jdbcTemplate.query(sql, this.chargeDueMapper, new Object[]
> {currentdate, ChargeTimeType.ANNUAL_FEE.getValue(),
> SavingsAccountStatusType.ACTIVE.getValue()});
> }{code}
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
