Hi Adam, Thanks for bringing attention to this. Date handling is definitely something we eventually need to take on. The issue you mentioned around daylight saving and not being able to keep a strictly monotonic creation date for transactions is definitely concerning.
I agree with your proposal, let's add timezone to every single database field. Best, Arnold On Fri, Jun 3, 2022 at 9:32 AM Ádám Sághy <adamsa...@gmail.com> wrote: > Dear Community, > > I was spending some time to understand in detail the date handling of > Fineract and i might learnt a gap which could be a potential problem when > the tenant (or system) timezone has daylight savings feature. > > Current behaviour: > - Some of the audit datetime fields are using system timezone (usually 3rd > party libs, like: quartz) > - Some of the audit datetime fields are using tenant timezone (usually the > fineract audit features, like: creation date, last modified date) > - We are storing them in DB without timezone attribute > > The problem: > - If a transaction (#1) was done at 2:59 AM 30th of October and 1 minutes > later we are adjusting the clock backward with an hour and the following > incoming a new transaction (#2) then the creation date will be 2:02 AM 30th > of October > > This potentially a huge problem if any logic is depending on the > creation date or using it for audit purposes. > > I would like to propose the following solution: > > - We should introduce Timezone aware datetime handling into Fineract and > also store the timezone attribute for these kind of date in the database > as well > > Should you have any question, please let me know! > > Regards, > Adam
