Split the core JVM variant up to create a separate Android variant

[erikc5000]

When trying out the new java.time desugaring support, I discovered that Android doesn't support ZoneRulesProvider at all (they've removed it from the docs entirely), relying on the ICU TimeZone class instead for its TZDB. That class is API 24 and above and unfortunately, not desugared as far as I can tell.

It should be possible to implement an Island Time TimeZoneRulesProvider that uses the android.icu.TimeZone class. Of course, with a minimum API version that's going to be a deal breaker for many right now.

It's unclear if there's any way to make this work with the Android default TZDB on older API versions -- short of typealiasing the Java 8 time classes anyway, which is not a road I'd like to go down.

Creating a time zone rules provider that packages its own TZDB, which can be used on any platform supported by Island Time might be an avenue worth pursuing in the long term, but the threetenabp-extensions will accomplish that for Android at the moment. Just with extra baggage in a world where java.time is desugared. Another option too is creating a derivative of threetenabp/threetenbp with all the non-TZDB essential parts removed.

There is definitely value in providing an option to package a TZDB rather than relying on a potentially outdated default. See recent Brazil time zones woes: https://www.reddit.com/r/androiddev/comments/e00swv/does_anyone_face_brazils_dst_related_issue_by/

Edit: My initial assessment was off. It's possible to get enough information from the available desugared java.time APIs to make everything work. It'll just require doing things a bit different on Android.

[erikc5000]

Android Studio 4.0's java.time library desugaring now works out of the box using the JVM variant. The current implementation is less than ideal and it may be good to split it up into a separate Android artifact. May also be worth looking into whether or not TimeZone should be typealiased to improve performance.

[erikc5000]

Would still like to restructure the core project to add an Android variant, making it a possible to handle some of the JVM/Android API disparities better. I think this might be something to hold off on until HMPP is introduced in Kotlin 1.4 though.