[ 
https://issues.apache.org/jira/browse/FINERACT-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Victor Jo updated FINERACT-1379:
--------------------------------
    Description: 
I'm currently running Fineract on AWS ECS Fargate. Whenever a resource is 
created on the system (client, savings account etc.), the dates are moved back 
by one before eventually persisted. Note, when running locally, the dates are 
persisted correctly just as it should be.

I put some logs and inspected them on aws cloudwatch to really track the 
process.

 

>From the attached image. The *{color:#172b4d}JsonParserHelper{color}* 
>correctly extracts the dates from the request body.

Then the logs from the *Client* class shows the final date after
{code:java}
Date.from(activationDate.atStartOfDay(DateUtils.getDateTimeZoneOfTenant()).toInstant());{code}
{color:#172b4d}is executed for the respective parameters (in this case: 
submittedOnDate, activationDate and officeJoiningDate). The tenants on the 
system all have timezones on the  *_fineract_tenants.tenants_* table
 
 This same thing happens on other parts of the project where a date is being 
used.
 
 
 I tried changing the time zone on my docker container but that didn't 
work.{color}

{color:#172b4d}Does any one have any suggestions [~vorburger]   ? Thanks.{color}

  was:
I'm currently running Fineract on AWS ECS Fargate. Whenever a resource is 
created on the system (client, savings account etc.), the dates are moved back 
by one before eventually persisted. Note, when running locally, the dates are 
persisted correctly just as it should be.

I put some logs and inspected them on aws cloudwatch to really track the 
process.

 

>From the attached image. The *{color:#172b4d}JsonParserHelper{color}* 
>correctly extracts the dates from the request body.

Then the logs from the *Client* class shows the final date after
{code:java}
Date.from(activationDate.atStartOfDay(DateUtils.getDateTimeZoneOfTenant()).toInstant());{code}
{color:#172b4d}is executed for the respective parameters (in this case: 
submittedOnDate, activationDate and officeJoiningDate). The tenants on the 
system all have timezones on the  *_fineract_tenants.tenants_* table
 
 This same thing happens on other parts of the project where a date is being 
used.
 
 
 I tried changing the time zone on my docker container but that didn't 
work.{color}

{color:#172b4d}Does any one have any suggestions ? Thanks.{color}


> Dates are one day off before saved
> ----------------------------------
>
>                 Key: FINERACT-1379
>                 URL: https://issues.apache.org/jira/browse/FINERACT-1379
>             Project: Apache Fineract
>          Issue Type: Task
>    Affects Versions: 1.5.0
>            Reporter: Victor Jo
>            Priority: Major
>         Attachments: cloud_watch_logs_ecs.png
>
>
> I'm currently running Fineract on AWS ECS Fargate. Whenever a resource is 
> created on the system (client, savings account etc.), the dates are moved 
> back by one before eventually persisted. Note, when running locally, the 
> dates are persisted correctly just as it should be.
> I put some logs and inspected them on aws cloudwatch to really track the 
> process.
>  
> From the attached image. The *{color:#172b4d}JsonParserHelper{color}* 
> correctly extracts the dates from the request body.
> Then the logs from the *Client* class shows the final date after
> {code:java}
> Date.from(activationDate.atStartOfDay(DateUtils.getDateTimeZoneOfTenant()).toInstant());{code}
> {color:#172b4d}is executed for the respective parameters (in this case: 
> submittedOnDate, activationDate and officeJoiningDate). The tenants on the 
> system all have timezones on the  *_fineract_tenants.tenants_* table
>  
>  This same thing happens on other parts of the project where a date is being 
> used.
>  
>  
>  I tried changing the time zone on my docker container but that didn't 
> work.{color}
> {color:#172b4d}Does any one have any suggestions [~vorburger]   ? 
> Thanks.{color}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to