Backport of functionality based on JSR-310 to Java SE 6 and 7. This is NOT an implementation of JSR-310.

I haven't been able to reproduce this myself, but I am getting reports from the wild that sometimes LocalDate.format() is returning an invalid result on some Android devices. (Using https://github.com/JakeWharton/ThreeTenABP.)

Here's what happens, as confirmed by the log call in this method.

• On entry to this method, month is 2016-08.
• startOfMonth is correctly set to 2016-08-01.
• monthString gets set to 0000-00-00 which is wrong.

private Observable<Void> ensureDataForMonthExistsInternal(YearMonth month) {
    final LocalDate startOfMonth = month.atDay(1);
    final String    monthString  = startOfMonth.format(DateTimeFormatter.ISO_LOCAL_DATE);
    Timber.i("Calling ensureDataForMonthExists with month %s, as date %s, formatted %s", month, startOfMonth, monthString);

So far the issue seems to affect only Motorola devices running Android 6.0.

Does threetenbp actually use possibly-broken system APIs for date formatting? Or is it completely self-contained? Intuitively, my expectation is that using DateTimeFormatter.ISO_LOCAL_DATE should not require the locale or any other information to be read from the system.

This was originally reported as https://github.com/JakeWharton/ThreeTenABP/issues/33.

Complex applications making use of a custom initializer occasionally run into issues where the implicit static initialization has been called before the explicit one has had a chance to run. Of course the solution is to ensure that the custom initializer is set up before anything else happens in the process, but in large codebases accomplishing this is sometimes more complex than it should be, and references to ThreeTenBP that trigger ZoneRulesProvider can sometimes slip through earlier in the startup sequence. When that happens, an "Already initialized" crash happens at the intentional explicit setInitializer call, but it is difficult to find the source of the implicit initialization. I propose on any initializer set, implicit or explicit, keep track of the stack trace so that a potential future "Already initialized" error can include the stack trace of the earlier call.

My proposal is to update AtomicReference<ZoneRulesInitializer> INITIALIZER to store both a ZoneRulesInitializer as well as a StackTraceElement[]. For completeness, maybe also replace AtomicBoolean INITIALIZED with an AtomicReference<StackTraceElement[]>, to keep track of both setInitializer and initialize calls as both can later cause issues. When the IllegalStateExceptions are thrown, add a new exception as its cause with the stack trace set to the appropriate saved one. It might even be best to include both in the case of duplicate initialization, where the IllegalStateException would be caused by the duplicate initialization exception which would be caused by the set initializer stack trace (if it exists).

Thoughts? This is something I can put into code form if it seems like the appropriate approach to this problem.

Originally reported here: https://github.com/JakeWharton/ThreeTenABP/issues/41

Version:

1.0.3

Exception:

org.threeten.bp.zone.ZoneRulesException: Unknown time-zone ID: Asia/Hanoi
    at org.threeten.bp.zone.ZoneRulesProvider.getProvider(ZoneRulesProvider.java:178)
    at org.threeten.bp.zone.ZoneRulesProvider.getRules(ZoneRulesProvider.java:133)
    at org.threeten.bp.ZoneRegion.ofId(ZoneRegion.java:143)
    at org.threeten.bp.ZoneId.of(ZoneId.java:357)
    at org.threeten.bp.ZoneId.of(ZoneId.java:285)
    at org.threeten.bp.ZoneId.systemDefault(ZoneId.java:244)
    at<>.(DateAgoFormatter.java:45)
    at <>.(ThreadCardViewCreator.java:533)
    at <>.(ThreadCardViewCreator.java:324)
    at <>.(ThreadCardViewCreator.java:283)
    at <>.(ThreadCardViewCreator.java:71)
    at <>.(Card.java:30)
    at <>.(BaseFeedAdapter.java:91)
    at android.widget.HeaderViewListAdapter.getView(HeaderViewListAdapter.java)
    at android.widget.AbsListView.obtainView(AbsListView.java)
    at android.widget.ListView.makeAndAddView(ListView.java)
    at android.widget.ListView.fillDown(ListView.java)
    at android.widget.ListView.fillFromTop(ListView.java)
    at android.widget.ListView.layoutChildren(ListView.java)
    at android.widget.AbsListView.onLayout(AbsListView.java)
    at android.view.View.layout(View.java)
    at android.view.ViewGroup.layout(ViewGroup.java)
    at android.widget.FrameLayout.layoutChildren(FrameLayout.java)
    at android.widget.FrameLayout.onLayout(FrameLayout.java)
    at android.view.View.layout(View.java)
    at android.view.ViewGroup.layout(ViewGroup.java)
    at android.widget.FrameLayout.layoutChildren(FrameLayout.java)
    at android.widget.FrameLayout.onLayout(FrameLayout.java)
    at android.view.View.layout(View.java)
    at android.view.ViewGroup.layout(ViewGroup.java)
    at android.support.v4.widget.SwipeRefreshLayout.onLayout(SwipeRefreshLayout.java:598)
    at android.view.View.layout(View.java)
    at android.view.ViewGroup.layout(ViewGroup.java)
    at android.widget.FrameLayout.layoutChildren(FrameLayout.java)
    at android.widget.FrameLayout.onLayout(FrameLayout.java)
    at android.view.View.layout(View.java)
    at android.view.ViewGroup.layout(ViewGroup.java)
    at android.support.design.widget.HeaderScrollingViewBehavior.layoutChild(HeaderScrollingViewBehavior.java:122)
    at android.support.design.widget.ViewOffsetBehavior.onLayoutChild(ViewOffsetBehavior.java:42)
    at android.support.design.widget.AppBarLayout$ScrollingViewBehavior.onLayoutChild(AppBarLayout.java:1192)
    at android.support.design.widget.CoordinatorLayout.onLayout(CoordinatorLayout.java:814)
    at android.view.View.layout(View.java)
    at android.view.ViewGroup.layout(ViewGroup.java)
    at android.support.v4.widget.DrawerLayout.onLayout(DrawerLayout.java:1191)
    at android.view.View.layout(View.java)
    at android.view.ViewGroup.layout(ViewGroup.java)
    at android.widget.FrameLayout.layoutChildren(FrameLayout.java)
    at android.widget.FrameLayout.onLayout(FrameLayout.java)
    at android.view.View.layout(View.java)
    at android.view.ViewGroup.layout(ViewGroup.java)
    at android.widget.FrameLayout.layoutChildren(FrameLayout.java)
    at android.widget.FrameLayout.onLayout(FrameLayout.java)
    at android.view.View.layout(View.java)
    at android.view.ViewGroup.layout(ViewGroup.java)
    at android.widget.FrameLayout.layoutChildren(FrameLayout.java)
    at android.widget.FrameLayout.onLayout(FrameLayout.java)
    at android.view.View.layout(View.java)
    at android.view.ViewGroup.layout(ViewGroup.java)
    at android.widget.LinearLayout.setChildFrame(LinearLayout.java)
    at android.widget.LinearLayout.layoutVertical(LinearLayout.java)
    at android.widget.LinearLayout.onLayout(LinearLayout.java)
    at android.view.View.layout(View.java)
    at android.view.ViewGroup.layout(ViewGroup.java)
    at android.widget.FrameLayout.layoutChildren(FrameLayout.java)
    at android.widget.FrameLayout.onLayout(FrameLayout.java)
    at android.view.View.layout(View.java)
    at android.view.ViewGroup.layout(ViewGroup.java)
    at android.view.ViewRootImpl.performLayout(ViewRootImpl.java)
    at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java)
    at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java)
    at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java)
    at android.view.Choreographer$CallbackRecord.run(Choreographer.java)
    at android.view.Choreographer.doCallbacks(Choreographer.java)
    at android.view.Choreographer.doFrame(Choreographer.java)
    at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java)
    at android.os.Handler.handleCallback(Handler.java)
    at android.os.Handler.dispatchMessage(Handler.java)
    at android.os.Looper.loop(Looper.java)
    at android.app.ActivityThread.main(ActivityThread.java)
    at java.lang.reflect.Method.invoke(Native Method)
    at java.lang.reflect.Method.invoke(Method.java:372)
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java)

This branch contains test cases for three bugs reported at OpenJDK. I've written new tests but I can't really write the code that fixes them as I would be using knowledge of GPL code to do so. Looking for someone to take on this issue.

Thanks your library help to develop, but I find an exception when I used "LocalDate.now().dayOfWeek.getDisplayName(TextStyle.NARROW or STANDALONG, Locale.getDefault())". My Location and device region is China, System language is Chinese. For example, today is Wednesday, the correct result should be “三” (third) instead of "星" and other day's result is "星" which should be "一、二、三...". When I set locale to US, the result is "W", it's right.

Preserves the default behavior of obtaining a ZoneRulesProvider instance from ServiceLoader, but adds the ability to substitute in different initialization code that will be executed in the static block of ZoneRulesProvider the first time that time zone rules are needed.

A more flexible replacement for https://github.com/ThreeTen/threetenbp/pull/64.

When the timezone DB isn't included in the JAR, the code to look for it and load it with ServiceLoader should be removed from the static initializer block of ZoneRulesProvider. Apparently ServiceLoader is extremely slow on Android even if there are no implementations loaded (since no-tzdb already handles removing the META-INF entry), and it's not needed when the code isn't bundled with a tzdb.

I was trying to figure out some Maven incantation to exclude this version of the class and include an alternate version that removes the static initializer block, but I've never used Maven before so I'm lost :)

I need to differentiate between LocalDate instances by a long/int value. This is useful in this case, for example: https://developer.android.com/reference/android/support/v7/widget/RecyclerView.Adapter.html#getItemId(int)

I was told that hashCode isn't good enough: https://github.com/ThreeTen/threetenbp/issues/81

What can I do instead?

Hi,

Was the fix for https://bugs.openjdk.java.net/browse/JDK-8033662 backported to threetenbp? I seem to experience this bug with threetenbp 0.9.

Thanks, Viktor

This can solve #69 Dependent libraries can use DateTimeTextProvider.setInstance() to set their implementation of DateTimeTextProvider as default. As a side effect, if default instance is not set explicitly, only one instance of SimpleDateTimeTextProvider will be created.

For the Android support, and in addition to the work towards #29, I need to load the TZDB.dat from an alternative location. Right now I have to duplicate the entirety of TzdbZoneRulesProvider in my own class but inside of the org.threeten.bp.zone package for access to Ser (and its transitive dependencies). It would be of great convenience if TzdbZoneRulesProvider had either a static factory or constructor overload that accepted an InputStream for reading of its data.

org.threeten.bp.zone.ZoneRulesException: Unknown time-zone ID: Europe/Kyiv at android.app.ActivityThread.handleReceiver(ActivityThread.java:4233) at android.app.ActivityThread.access$1800(ActivityThread.java:274) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2109) at android.os.Handler.dispatchMessage(Handler.java:106) at android.os.Looper.loop(Looper.java:233) at android.app.ActivityThread.main(ActivityThread.java:8063) at java.lang.reflect.Method.invoke(Method.java) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:631) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:978)

Caused by org.threeten.bp.zone.ZoneRulesException: Unknown time-zone ID: Europe/Kyiv at org.threeten.bp.zone.ZoneRulesProvider.getProvider(ZoneRulesProvider.java:167) at org.threeten.bp.zone.ZoneRulesProvider.getRules(ZoneRulesProvider.java:122) at org.threeten.bp.ZoneRegion.ofId(ZoneRegion.java:143) at org.threeten.bp.ZoneId.of(ZoneId.java:358) at org.threeten.bp.ZoneId.of(ZoneId.java:286) at org.threeten.bp.ZoneId.systemDefault(ZoneId.java:245) at org.threeten.bp.Clock.systemDefaultZone(Clock.java:137) at org.threeten.bp.LocalDateTime.now(LocalDateTime.java:152)

This code using 1.6.1 version of threetenbp:

 org.threeten.bp.LocalDate
        .of(2020, 1, 1)
        .format(org.threeten.bp.format.DateTimeFormatter.ofPattern("QQQQ", Locale.FRANCE))

outputs: 1st quarter

And then the same code using Java 11 implementation it outputs the correct format:

    java.time.LocalDate
        .of(2020, 1, 1)
        .format(java.time.format.DateTimeFormatter.ofPattern("QQQQ", Locale.FRANCE))

outputs: 1er trimestre

The outputs should be also localized with threetenbp.

DateTimeFormatter giving different results;

val formatter = DateTimeFormatter.ofPattern("MMMM - yyyy").withChronology(HijrahChronology.INSTANCE); val now = HijrahChronology.INSTANCE.date(LocalDate.of(2022, 8, 29)); println(formatter.format(now))

The result is February 1444; Actually it should be Safar 1444;

I tested code like above with java.time.DateTimeFormatter and it worked as expected.

Similar to the issue raised in #97, the fix given only works if the user's device is in zh-CH. However, when a user is using a variation of Chinese like zh-TW or zh-HK the incorrect DayOfWeek translation for SHORT reappears, displaying "星" instead of "一、二、三...".

https://github.com/AdoptOpenJDK/openjdk-jdk/commit/08eb67b941ee4f9a490fc17535bc0c9209b91071#diff-c638e872b60894dedf26ea7893bf9e54d191d8fa2036a741d93c38b708c7ad52