Standardize DB chronological fields to DateTime + make the Talawa clients store DateTime in UTC

[palisadoes]

The Talawa applications assume that the:

1. user and organization are in the same timezone
2. API server and the organization are in the same timezone

This will create confusion when an organization’s stakeholders and its service providers are geographically dispersed.

For example someone someone in the US state of New Mexico creating and event in neighboring Texas will have concerns. There are some cities in the USA like Minneapolis and Kansas City that straddle timezones.

Describe the solution you'd like

The client must:

1. Only update the database with date values in UTC. This means you will have to use the local timezone of the client as the basis for converting database times to UTC.
2. Convert dates read from the database to the local timezone of the client for presentation to the end user

The API must:

1. Store all DB chronological fields to DateTime even if the data stored is just a date for standardized consistency

There must be a date data conversion function that is used to make this consistent.

Related issues and PRs (closed):

1. Standardized and Added UTC conversion for Date and Time talawa-admin#1900
2. Admin - Set Organization Timezone Feature talawa-admin#1800
3. API - Set Organization Timezone Feature #2096
4. Admin: Store all dates in the database in UTC talawa-admin#1813
5. Mobile: Store all dates in the database in UTC talawa#2446

Potential Approach

As per this comment:

• Standardized and Added UTC conversion for Date and Time talawa-admin#1900 (comment)

1. Create a separate branch to fix the UTC conversions.
2. Work on making the entire code base DateTime consistent.
3. Accommodate UTC conversions.
4. Make sure that nothing breaks and everything works as expected.
5. Merge the DateTime branch into develop.

Other

This discussion is created to try to decide on a plan of action before we open issues and create a slack channel. We need to determine whether:

1. this is worthwhile and
2. the resources to do it are available

[palisadoes]

1. @meetulr
2. @aarishshahmohsin
3. @Azad99-9

We can discuss this further here. Creating the branches are easy. I want to understand how we can create specific issues to easily get the work done. It would seem to me that it would be best to do this a collection at a time.

[palisadoes]

This link was mentioned in a slack discussion. It's a possible approach.

• https://www.linkedin.com/advice/0/how-can-you-design-mobile-applications-optimal-2ie0c?utm_source=share&utm_medium=member_android&utm_campaign=share_via

[varshith257]

@palisadoes I will try to give the planned approach we can follow for implementation of it by the weekend.

[meetulr]

Yes, we need to first clarify what exactly is required and how to implement it. Like how are things right now and how do we want them to be, in terms of implementation. i.e. the exact flow of things.

I'll start researching on it properly in a couple days. I'm currently focusing on completing recurring events😅

We could all share useful resources here.

[Azad99-9]

For Talawa we can architect the application by centralizing these timezone conversions. Same as we are following for the Talawa AppLanguage now.

In this process we can make use of this useful TimeZone package.

https://www.dhiwise.com/post/setting-up-the-flutter-timezone-package-in-your-app

[xoldd]

The usage of graphQL scalars Time, Date and Datetime in the graphQL schema ensures that the time/date/datetime strings exchanged between the clients and graphQL api are always UTC compliant.

Four possible causes for any issues that have occurred related to handling of these values in talawa applications:-

1. Not annotating the type for fields corresponding to those time/date/datetime as the corresponding graphQL scalars in the graphQL schema. One example is using dateOfBirth: String instead of dateOfBirth: Date in the graphQL schema.
2. Client sending incorrect UTC compliant time/date/datetime strings. One example is the client sending the date of birth for a living human 10000 years in the past which makes no sense as no human can live that long.
3. Server accidently/incorrectly mutating or failing to implement the correct business logic on the received UTC compliant time/date/datetime strings before storing them in the database. One example is server not checking that the date of birth for a living human sent by the client is no bigger than 100-150 years in the past.
4. Since there is a latency between the client and server, the location where creation of time/date/datetime strings takes place could introduce discrepancies. For example the creation of createdAt datetime field for a database record can be handled both on the client and the server. But since there's a difference of latency between those applications, the createdAt datetime field created on the server is not actually the real datetime at which the record associated to that field was created by the client application.

Talawa-api returning localized time/date/datetime strings would be needless technical debt. On the talawa client applications the UTC time/date/datetime strings returned from the server have to be localized according to physical location of the client. Most modern programming languages and libraries provide this feature.

[meetulr]

The straightforward way would be to just send everything in UTC from the frontend, store it as such, and then get it back and convert back to local time on the frontend like you said.

But we would need the time part for those conversions, right? Like how would we handle conversions with graphql Date type? Woudn't we need DateTime for that?

[xoldd]

But we would need the time part for those conversions, right? Like how would we handle conversions with graphql Date type? Woudn't we need DateTime for that?

I was meaning to say that the ISO 8601 standard that UTC follows also describes what standard Date and Time strings should look like. Of course just the Date or Time strings individually cannot be used to localize the Datetime information.

[meetulr]

I should have been clearer😅 I thought you were implying that there's a way to handle these things with our current implementation. I was meaning to ask if there is, but I guess not😅

[pranshugupta54]

We should prefer asking the user than asking for permissions, users don’t find it good when an application asks for too many permissions. “Why would this app wanna know my location? They’re going to track me? Feels unsafe!”

We can modify the API to ask for date time along with timezone? or use the iso formatting to include timezone too. Like 2018-02-01T12:52:34+09:00 and then convert it on the server

[meetulr]

The device on which the code is running would generate date objects based on that client's time zone right? I'm talking about sending those to the backend after conversions, and then getting them back and convert back to client's time again.

[pranshugupta54]

Does it not require location permissions? 🤔For mobiles

[meetulr]

Does it?🤔 I guess we'll learn😅. Generating the javascript date objects... the code would run on the browser's time for the web app. For mobile though @Azad99-9?

[Azad99-9]

All the DateTime objects created in the mobile client will be based on the system(mobile) clock.

Almost all device's system clocks will have timezones set implicitly based on either of the below means:

1. Network - provided time
2. GPS - provided time

However, both means provide accurate information about the user's current timezone.

So the user's current timezone will be handled by the mobile device itself. We explicitly asking the user for location permission for the current timezone would not be necessary on the mobile part.

[palisadoes]

The client's timezone should be easy to get from its operating system.

[palisadoes]

Regarding the DB schema we should consider updating Calendar / Event fields to be DateTime to assist with this transition.

[Azad99-9]

If the client-side conversion is preferred. Then we are required to update all date, time related fields in the mobile application also to accommodate DateTime type.

[palisadoes]

The RRULE package being used in the API for recurring events already uses the ISO 8601 format. We have precedent for adopting this methodology

• https://www.npmjs.com/package/rrule

[meetulr]

Did someone look into this?😅

[pranshugupta54]

Timezone changes will surely affect too many screens (mostly Events) causing issue with GSoC and Calico 😅

[palisadoes]

We'll need to incorporate this into the requirements for all GSoC and Calico work.