Image for post
Image for post

Handling dates on Android

Thomas Wirth
Nov 27, 2020 · 4 min read

Is Core Library Desugaring the holy grail?

As a mobile developer you most probably had to parse dates and maybe even consider different time zones and daylight saving times. Many apps still make use of java.util.Date, java.util.Calendar and java.text.SimpleDateFormat classes. These are legacy classes with a long history in the Java world, which were replaced with the Date and Time API (JSR-310) in Java 8.

Disclaimer: This article is not a tutorial on how to implement different Date / Time libraries. The goal is to compare the current options and give advice on which to choose.

Time to switch

Let’s meet the candidates

1. Java 6/7 Date API (e.g. java.util.Date, java.util.Calendar)

  • Date is instant in time, doesn’t represent an actual date (no time zone, no format, no calendar system)
  • Classes are mutable, no thread-safety, Calendar class is not type safe
  • Unintuitive API (month is zero indexed, DayOfWeek != ISO 8601, lenient by default, implicit usage of the system-local)

There are more detailed articles about the issues of java.util.Date.

2. JodaTime (JodaTime Android)

3. ThreeTenBP (ThreeTenABP)

4. Core Library Desugaring

5. kotlinx-datetime

Comparing features of the date time libraries / framework
Comparing features of the date time libraries / framework
Comparing features of the date time libraries

Impact on the artifact

Table of the impact in size and dex count.
Table of the impact in size and dex count.
Comparing artifact size and dex count of the date time libraries

As you can see from my comparison, core library desugaring has a noticeable footprint. There are several reasons. The desugaring process currently adds the Java 8 and util.concurrent packages to the APK (~3K methods) even if you don’t make use of it (D8/R8 doesn’t shrink them). There is an issue in the issue tracker about this. Also the desugaring relies on multidex, even if your total dexcount is below 64K. This slightly increases the APK size, so in the end the app is larger than with JodaTime or ThreeTenABP (even though these libraries ship their own timezone db).


So you should definitely try out core library desugaring. We at NanoGiants already migrated our apps and haven’t run into any issues (you should enable R8 to avoid issues on API 23).

The comparison also shows that the libraries have different impact on the final app size and method count. If you care about minimal size, it’s maybe worth to stick to ThreeTenABP for a little longer. Also migrating from ThreeTenABP to Java 8 later on is absolutely straightforward — as the API is the same and you just need to change your imports.

Have a nice LocalDateTime!


Choose to Grow

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store