Noted thanks for clarifying this Adam. Practically we use CAT over 3 different countries therefore this conversion means where we normally had 01:00AM CAT it would now display 11:00PM GMT +2 Hours right? If this is the case that would be a significant difference from what we are used to and not a very popular scenario.
With regards to applying timestamps with timezones. I think that is a good idea, if it may pick the timezone applicable to that region correct to the user settings in the tenant table that would be perfect. Regards, -----Original Message----- From: Ádám Sághy <[email protected]> Sent: Monday, 06 June 2022 10:25 AM To: [email protected] Cc: Ádám Sághy <[email protected]> Subject: Re: Timezone issues with Daylight savings Hi Sifiso, I believe by adding and storing the Timezone details of the date time fields in the database will not have any impact to the user device locale behaviour. This approach will not change the way of the Fineract is using the user locale information. The proposed solution would change the following things only: - In the database the TIMESTAMP (without timezone) fields to be changed to “TIMESTAMP WITH TIME ZONE” - Instead of fetching/storing (with JPA) these fields as java.util.Date, it will be “java.time.OffsetDateTime" - Same applies for the native queries The main reason is to overcome the probable Daylight Savings issues if only a “moment" is stored in database (without timezone or offset information) I hope it helps to understand better. Should you have any question, please let me know! Regards Adam > On 6 Jun 2022, at 08:09, [email protected] wrote: > > Hi Adam, > > Thank you for sharing. Just wanted to know what the impact of having a > server located in a different continent to the user would be? Using > this approach will it pickup the user device's date settings automatically? > > > > > -----Original Message----- > From: Ádám Sághy <[email protected]> > Sent: Friday, 03 June 2022 9:32 AM > To: [email protected] > Cc: Ádám Sághy <[email protected]> > Subject: Timezone issues with Daylight savings > > 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 >
