Replace joda-time with java.time APIs

[PattaFeuFeu]

Checklist

• [x] I made sure that there are no existing issues - open or closed - to which I could contribute my information.
• [ ] I have read the FAQ and my problem isn't listed.
• [x] I have taken the time to fill in all the required details. I understand that the feature request will be dismissed otherwise.
• [x] This issue contains only one feature request.
• [x] I have read and understood the contribution guidelines.

Is your feature request related to a problem? Please describe.

Calendar currently uses Joda-Time in most parts. Joda-Time has been more or less deprecated since Java8 and with it java.time came to be. It will no longer get any feature upgrades or active maintenance:

Joda-time is no longer in active development except to keep timezone data up to date. From Java SE 8 onwards, users are asked to migrate to java.time (JSR-310) - a core part of the JDK which replaces this project. For Android users, java.time is added in API 26+. Projects needing to support lower API levels can use the ThreeTenABP library.

Describe the solution you'd like

I would like to implement a solution based on java.time. Java 8 library such as java.time are officially only supported with API level 26, but it’s possible to use them in older API levels such as 23 used by this app by using core library desugaring. I’ve used that in the past and it worked well, so I’d like to propose that solution here.

I would also like to replace all usages of java.util.Calendar, java.text.SimpleDateFormat wherever possible—java.time and its formatters can make sure that time zones across different centuries work, and that formatting is a breeze.

Additional context

[!NOTE] Before I start, given that this will be some work, I’d like to ask for an OK first. 😊

If it is okay, please assign me this issue and I’ll get to it.

[Aga-C]

@naveensingh Please check this.

[naveensingh]

@PattaFeuFeu

Since we are still starting out, we are focusing more on bug fixes than rewriting/modernizing code. You are welcome to work on this and I don't want to demotivate you but know that this is going to involve a lot of time-consuming testing (manual and otherwise) to ensure everything works properly in different timezones because the PR won't get merged until it works properly. For common tz-related issues, you can refer to existing and closed issues on SMT and here.

Thanks.

[PattaFeuFeu]

@naveensingh Speaking of testing: I was quite astonished that there’s not a single unit test in this codebase. Is there a reason for that?

[naveensingh]

@PattaFeuFeu no reason at all. All the apps were developed by a single person with no unit tests and it just stayed that way.