threeten / threetenbp Goto Github PK

In case of polish locale("pl", "PL"), the library returns incorrect translations.

Example:

Locale locale = PartnerManager.getInstance().getConfig().market.locale;
return Month.of(month).getDisplayName(TextStyle.FULL_STANDALONE, locale);

returns stycznia (genitive) - should be Styczeń (nominative, standalone)

The correct translations are:
jan) stycznia -> Styczeń
feb) lutego -> Luty
mar) marca - > Marzec
apr) kwietnia -> Kwiecień
may) maja -> Maj
jun) czerwca -> Czerwiec
jul) lipca -> Lipiec
aug) sierpnia -> Sierpień
sep) września -> Wrzesień
oct) października -> Październik
nov) listopada -> Listopad
dec) grudnia -> Grudzień

Originally reported here: JakeWharton/ThreeTenABP#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)

DateTimeFormatter.ISO_OFFSET_DATE_TIME.parse("2001-07-04T12:08:56.235-0700");
DateTimeFormatter.ISO_OFFSET_DATE_TIME.parse("2001-07-04T12:08:56.235-07");

and

DateTimeFormatter.ISO_DATE_TIME.parse("2001-07-04T12:08:56.235-0700");
DateTimeFormatter.ISO_DATE_TIME.parse("2001-07-04T12:08:56.235-07");

throw DateTimeParseException

Issue:
Currently LocalDateTime is fed to Timestamp using (years, month, day, hours, minutes, seconds, nanos) constructor. This constructor calls through to Date constructor which uses current time zone to convert individual fields to millis. This results in wrong value being stored when working in non-UTC time zone. Similar approach (using individual fields) is used and issue encountered on the way back.

Solution:
LocalDateTime has to be converted to epoch millis/nanos before feeding it to Timestamp constructor. Then only getTime() can be called to safely retrieve original value.

I tried:

  DateTimeFormatter zf =
    DateTimeFormatter.ofPattern("zzzz", Locale.ENGLISH).withZone(ZoneId.of("America/Los_Angeles"));
  System.out.println(LocalDateTime.now().format(zf)); // Pacific Time

This code compiles in Java-8 (v1.8.0_77), is runnable and yields the expected result ("Pacific Time"). However, using ThreetenBP fails with following exception:

Exception in thread "main" org.threeten.bp.temporal.UnsupportedTemporalTypeException: Unsupported field: InstantSeconds
    at org.threeten.bp.LocalDate.get0(LocalDate.java:593)
    at org.threeten.bp.LocalDate.getLong(LocalDate.java:572)
    at org.threeten.bp.LocalDateTime.getLong(LocalDateTime.java:628)
    at org.threeten.bp.format.DateTimePrintContext$1.getLong(DateTimePrintContext.java:181)
    at org.threeten.bp.format.DateTimeFormatterBuilder$ZoneTextPrinterParser.print(DateTimeFormatterBuilder.java:3370)
    at org.threeten.bp.format.DateTimeFormatterBuilder$CompositePrinterParser.print(DateTimeFormatterBuilder.java:1995)
    at org.threeten.bp.format.DateTimeFormatter.formatTo(DateTimeFormatter.java:1385)
    at org.threeten.bp.format.DateTimeFormatter.format(DateTimeFormatter.java:1359)
    at org.threeten.bp.chrono.ChronoLocalDateTime.format(ChronoLocalDateTime.java:263)
    at org.threeten.bp.LocalDateTime.format(LocalDateTime.java:1828)

I remember our discussion on stackoverflow. Following questions:

• Is the observed exception a bug or a feature of ThreetenBP?
• Are there any plans to update ThreetenBP to newer subversions of Java-8 (higher than 8u20)?
• If a solution for given code above is not possible then how can I achieve the generic non-location name of a time zone in a different way?

Invoking #nextTransition() or #previousTransition() on a StandardZoneRules instance with no historic transitions present causes an ArrayIndexOutOfBoundsException to be thrown:

ZoneId.of("Etc/GMT").getRules().nextTransition(Instant.EPOCH);

This is caused by indexing the (empty) array of historic transitions in the StandardZoneRules class:

public ZoneOffsetTransition nextTransition(Instant instant) {
    long epochSec = instant.getEpochSecond();

    // check if using last rules
    if (epochSec >= savingsInstantTransitions[savingsInstantTransitions.length - 1]) {
        [...]
    }

    [...]
}

Since the return value of this method is documented to be nullable, it seems to make more sense to return null. This matches the behavior of java.time.zone.ZoneRules#nextTransition() in JDK8, which contains a (length == 0) check:

public ZoneOffsetTransition nextTransition(Instant instant) {
    if (savingsInstantTransitions.length == 0) {
        return null;
    }

    [...]
}

ZonedDateTime serialization relies in the serialization of ZoneOffset. However, ZoneOffset has a transient id field that is not handled correctly: when deserializing a ZoneOffset, only the totalSeconds field is recovered. The id will be null and the toString method will return "null".

What went wrong:

ART runtime fails to load the SimpleDateTimeTextProvider class when DateTimeFormatBuilder is referenced on Android Lollipop. The app crashes immediately.

Note that the library jar is fetched from the maven central repository.

Steps to reproduce:

1.Create a new Project in Android Studio

1. Add compile 'org.threeten:threetenbp:1.1' to the dependencies section in app.gradle
2. Add DateTimeFormatter test = DateTimeFormatter.ofPattern("HH:mm"); to MainActivity.onCreate().
3. Run the app in emulator running Android Lollipop, and the app crashes.

Stacktrace from my emulator:

I/ActivityManager( 1297): Start proc com.example.yourapplication for activity com.example.yourapplication/.MainActivity: pid=2012 uid=10053 gids={50053, 9997} abi=x86_64
E/art     ( 2012): Failed writing handshake bytes (-1 of 14): Broken pipe
I/art     ( 2012): Debugger is no longer active
I/art     ( 2012): Rejecting re-init on previously-failed class java.lang.Class<org.threeten.bp.format.DateTimeTextProvider>
I/art     ( 2012): Rejecting re-init on previously-failed class java.lang.Class<org.threeten.bp.format.DateTimeTextProvider>
I/art     ( 2012): Rejecting re-init on previously-failed class java.lang.Class<org.threeten.bp.format.DateTimeFormatterBuilder$2>
I/art     ( 2012): Rejecting re-init on previously-failed class java.lang.Class<org.threeten.bp.format.DateTimeFormatterBuilder$2>
I/art     ( 2012): Rejecting re-init on previously-failed class java.lang.Class<org.threeten.bp.format.DateTimeTextProvider>
I/art     ( 2012): Rejecting re-init on previously-failed class java.lang.Class<org.threeten.bp.format.DateTimeTextProvider>
I/art     ( 2012): Rejecting re-init on previously-failed class java.lang.Class<org.threeten.bp.format.SimpleDateTimeTextProvider>
I/art     ( 2012): Rejecting re-init on previously-failed class java.lang.Class<org.threeten.bp.format.SimpleDateTimeTextProvider>
D/AndroidRuntime( 2012): Shutting down VM
--------- beginning of crash
E/AndroidRuntime( 2012): FATAL EXCEPTION: main
E/AndroidRuntime( 2012): Process: com.example.yourapplication, PID: 2012
E/AndroidRuntime( 2012): java.lang.NoClassDefFoundError: Failed resolution of: Lorg/threeten/bp/format/SimpleDateTimeTextProvider;
E/AndroidRuntime( 2012):    at org.threeten.bp.format.SimpleDateTimeTextProvider$LocaleStore.<init>(SimpleDateTimeTextProvider.java:333)
E/AndroidRuntime( 2012):    at org.threeten.bp.format.DateTimeFormatterBuilder.appendText(DateTimeFormatterBuilder.java:726)
E/AndroidRuntime( 2012):    at org.threeten.bp.format.DateTimeFormatter.<clinit>(DateTimeFormatter.java:608)
E/AndroidRuntime( 2012):    at com.example.yourapplication.MainActivity.onCreate(MainActivity.java:19)
E/AndroidRuntime( 2012):    at android.app.Activity.performCreate(Activity.java:5933)
E/AndroidRuntime( 2012):    at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1105)
E/AndroidRuntime( 2012):    at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2251)
E/AndroidRuntime( 2012):    at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2360)
E/AndroidRuntime( 2012):    at android.app.ActivityThread.access$800(ActivityThread.java:144)
E/AndroidRuntime( 2012):    at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1278)
E/AndroidRuntime( 2012):    at android.os.Handler.dispatchMessage(Handler.java:102)
E/AndroidRuntime( 2012):    at android.os.Looper.loop(Looper.java:135)
E/AndroidRuntime( 2012):    at android.app.ActivityThread.main(ActivityThread.java:5221)
E/AndroidRuntime( 2012):    at java.lang.reflect.Method.invoke(Native Method)
E/AndroidRuntime( 2012):    at java.lang.reflect.Method.invoke(Method.java:372)
E/AndroidRuntime( 2012):    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:899)
E/AndroidRuntime( 2012):    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:694)
E/AndroidRuntime( 2012): Caused by: java.lang.ClassNotFoundException: Didn't find class "org.threeten.bp.format.SimpleDateTimeTextProvider" on path: DexPathList[[zip file "/data/app/com.example.yourapplication-1/base.apk"],nativeLibraryDirectories=[/vendor/lib64, /system/lib64]]
E/AndroidRuntime( 2012):    at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:56)
E/AndroidRuntime( 2012):    at java.lang.ClassLoader.loadClass(ClassLoader.java:511)
E/AndroidRuntime( 2012):    at java.lang.ClassLoader.loadClass(ClassLoader.java:469)
E/AndroidRuntime( 2012):    ... 17 more
E/AndroidRuntime( 2012):    Suppressed: java.lang.NoClassDefFoundError: org.threeten.bp.format.SimpleDateTimeTextProvider
E/AndroidRuntime( 2012):        at dalvik.system.DexFile.defineClassNative(Native Method)
E/AndroidRuntime( 2012):        at dalvik.system.DexFile.defineClass(DexFile.java:222)
E/AndroidRuntime( 2012):        at dalvik.system.DexFile.loadClassBinaryName(DexFile.java:215)
E/AndroidRuntime( 2012):        at dalvik.system.DexPathList.findClass(DexPathList.java:321)
E/AndroidRuntime( 2012):        at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:54)
E/AndroidRuntime( 2012):        ... 19 more
E/AndroidRuntime( 2012):    Suppressed: java.lang.ClassNotFoundException: org.threeten.bp.format.SimpleDateTimeTextProvider
E/AndroidRuntime( 2012):        at java.lang.Class.classForName(Native Method)
E/AndroidRuntime( 2012):        at java.lang.BootClassLoader.findClass(ClassLoader.java:781)
E/AndroidRuntime( 2012):        at java.lang.BootClassLoader.loadClass(ClassLoader.java:841)
E/AndroidRuntime( 2012):        at java.lang.ClassLoader.loadClass(ClassLoader.java:504)
E/AndroidRuntime( 2012):        ... 18 more
E/AndroidRuntime( 2012):    Caused by: java.lang.NoClassDefFoundError: Class not found using the boot class loader; no stack available
W/ActivityManager( 1297):   Force finishing activity com.example.yourapplication/.MainActivity

Hello,
I am devising unit tests on the JVM where I need to create an instance:
ZonedDateTime dateTimeWithZone = ZonedDateTime.now();
However, I get an exception:

org.threeten.bp.zone.ZoneRulesException: No time-zone data files registered

Please advise.

org.threeten.bp.chrono.HijrahDate hijrahDate = org.threeten.bp.chrono.HijrahDate.now();
System.out.println(hijrahDate);

HijrahDate date = HijrahDate.now();
System.out.println(date);

outputs:

Hijrah-umalqura AH 1438-08-15
Hijrah-umalqura AH 1438-08-16

I just saw that a few of the recent commits linked to bugs in the OpenJDK bugtracker and code in the OpenJDK source repo.

Can you confirm that the code that ended up in this BSD-licensed repo has been contributed by the original author under this license? (I didn't look at the code as I'm very concerned about tainting myself by touching potentially license-incompatible code.)

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.

Because LocaleServiceProvider has been deleted.
https://android-review.googlesource.com/#/c/63554/

I removed LocaleServiceProvider implementations, it worked.
emonkak@eb3d777

For reasons mentioned in the android port, the loading of time zone information should be abstracted.

This way, a single library can be efficiently used across both java and android platforms.

My specific use case is that I have multiple pure java modules in my android project, and would like to share the API across both of them.

In org/threeten/bp are two jar files which contain another TZDB.dat file:
threeten-TZDB-2017b.jar
threeten-TZDB-all.jar

This affects both the regular and the no-tzdb artifacts of 1.3.5.

Try to meet demand for JDK 6 from @cdoremus and @dsmania

LocalDate.ofEpochDay(x) sometimes returns a wrong or illegal result instead of throwing an exception for large values of x. For instance, LocalDate.ofEpochDay(9223371671611556645L) returns a date with a negative value for d.getDayOfMonth() instead of throwing a DateTimeException.

Hello,

The following exception was reported on my project that uses threetenbp 1.0.

org.threeten.bp.zone.ZoneRulesException: Unknown time-zone ID: US/Pacific-New
    at org.threeten.bp.zone.ZoneRulesProvider.getProvider(ZoneRulesProvider.java:188)
    at org.threeten.bp.zone.ZoneRulesProvider.getRules(ZoneRulesProvider.java:143)
    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 org.threeten.bp.Clock.systemDefaultZone(Clock.java:137)
    at org.threeten.bp.LocalDateTime.now(LocalDateTime.java:152)

I have to admit that I'm at a loss.
I found this thread suggesting that this TimeZone is supposed to be supported.

Regards

I'm using the JSR 310 DateTime API (Java 7 and threetenbp) in my application, and I need to parse and format military date times (known as DTG or "date time group").

The format I'm parsing looks like this (using DateTimeFormatter):

"ddHHmm'Z' MMM yy" // (ie. "312359Z DEC 14", for new years eve 2014)

This format is fairly easy to parse as described above. The problem arises when the dates contains a different time zone than 'Z' (Zulu time zone, same as UTC/GMT), for example 'A' (Alpha, UTC+1:00) or 'B' (Bravo, UTC+2:00). See Military time zones for the full list.

How can I parse these time zones?

From what I understand, the generic format should be:

"ddHHmmz MMM yy"

I have created a ZoneRulesProvider with the all the named zones and correct offsets. But it still won't parse, as it seems that single character time zone ids (or "regions") other than 'Z' are not even allowed by the API.

For example:

ZoneId alpha = ZoneId.of("A"); // boom

Will throw DateTimeException: Invalid zone: A (without even accessing my rules provider to see if it exists). I get the same exception (wrapped in a DateTimeParseException) when trying to parse "312359A DEC 14" using the format above.

The behaviour is a little confusing, as the ZoneRulesProvider SPI registration does not complain about the "A" zone id. Meaning the zone will be registered, but unusable...

Is this an oversight in the API or a deliberate design decision? Or am I doing something wrong?

PS: See my StackOverflow question for background and discussion.

PPS: I realize this issue should maybe be filed against threeten, rather than threetenbp, but I'm sure you'll do the right thing. :-)

Regards,

Harald K

The documentation of public <T> T DateTimeFormatter.parse(CharSequence text, TemporalQuery<T> type) has the following example:

  LocalDateTime dt = parser.parse(str, LocalDateTime.class);

Which did work in previous versions of threeten but not in the current one.

How do I parse an Instant? Using version 0.8.1 I could simply do parser.parse(str, Instant.class) but that does not work anymore.

Update: To parse an Instant you have to invoke parser.parse(str, Instant.FROM) instead of parser.parse(str, Instant.class)

The JavaDoc for Duration.toHours() reads "Gets the number of minutes in this duration.", I guess that should be "hours".

Also false for toDays()

The ThreeTen project's integration into JDK 8 includes modifications to existing JDK datetime classes, e.g. a static factory method to create a java.sql.Timestamp from an Instant.

It should be within the scope of the backport to offer these conversion methods in a static utility class.

The following code will not throw a DateTimeParseException in the .parse(String) method:

  @Test
  public void testISOOptionalMonthOfYear(){
    DateTimeFormatter isoOptionalDayOfMonthFormatter =
            new DateTimeFormatterBuilder()
                    .appendValue(ChronoField.YEAR, 4, 4, SignStyle.NEVER)
                    .optionalStart()
                    .appendLiteral('-')
                    .appendValue(ChronoField.MONTH_OF_YEAR, 1, 2, SignStyle.NEVER)
                    .optionalEnd()
                    .toFormatter().withResolverStyle(ResolverStyle.STRICT);
    TemporalAccessor ta = isoOptionalDayOfMonthFormatter.parse("2016-40");
  }

But, the following code will throw a DateTimeParseException in the .parse(String) method:

  @Test
  public void testISOOptionalDayOfMonth(){
    DateTimeFormatter isoOptionalDayOfMonthFormatter =
            new DateTimeFormatterBuilder()
                    .appendValue(ChronoField.YEAR, 4, 4, SignStyle.NEVER)
                    .appendLiteral('-')
                    .appendValue(ChronoField.MONTH_OF_YEAR, 1, 2, SignStyle.NEVER)
                    .optionalStart()
                    .appendLiteral('-')
                    .appendValue(ChronoField.DAY_OF_MONTH, 1, 2, SignStyle.NEVER)
                    .optionalEnd()
                    .toFormatter().withResolverStyle(ResolverStyle.STRICT);
    TemporalAccessor ta = isoOptionalDayOfMonthFormatter.parse("2016-10-40");
  }

Seems strange to me, I was expecting the first test to also throw a DateTimeParseException instead of returning a DateTimeBuilder[fields={Year=2016, MonthOfYear=40}, ISO, null, null, null].

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.

Same use-case and motivations as JodaOrg/joda-time#220.

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 JakeWharton/ThreeTenABP#33.

org.threeten.bp.format.DateTimeTextProvider and org.threeten.bp.format.DateTimeFormatStyleProvider both implement java.util.spi.LocaleServiceProvider, which is not in the Google App Engine JRE whitelist: https://cloud.google.com/appengine/docs/java/jrewhitelist

I'm not sure why this was implemented this way, but the corresponding class in java.time don't implement this interface.

Could the interface be removed and the method "public Locale[] getAvailableLocales()" added to each class to ensure backward compat and allow thretenbp to run on GAE?

I'm implementing a Scala wrapper around the ThreeTen, when I my property testing throw an error when using the back port. The exception does not occur when testing against the JDK 8 implementation.

org.threeten.bp.format.DateTimeParseException: Text '+102158-09-10T12:10:32.251652071-01:00[Etc/GMT+1]' could not be parsed, unparsed text found at index 38
  at org.threeten.bp.format.DateTimeFormatter.parseToBuilder(DateTimeFormatter.java:1590)
  at org.threeten.bp.format.DateTimeFormatter.parse(DateTimeFormatter.java:1491)
  at org.threeten.bp.ZonedDateTime.parse(ZonedDateTime.java:562)
  at org.threeten.bp.ZonedDateTime.parse(ZonedDateTime.java:547)
  ... 43 elided

Example from console

scala> val bad = "+102158-09-10T12:10:32.251652071-01:00[Etc/GMT+1]"
bad: String = +102158-09-10T12:10:32.251652071-01:00[Etc/GMT+1]

scala> java.time.ZonedDateTime.parse(bad)
res0: java.time.ZonedDateTime = +102158-09-10T12:10:32.251652071-01:00[Etc/GMT+1]

scala> org.threeten.bp.ZonedDateTime.parse(bad)
org.threeten.bp.format.DateTimeParseException: Text '+102158-09-10T12:10:32.251652071-01:00[Etc/GMT+1]' could not be parsed, unparsed text found at index 38

I am trying to execute this piece of code:

 DateTimeFormatter dateTimeFormatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss VV", Locale.ENGLISH);
ZonedDateTime dateBuilt = ZonedDateTime.parse("2012-06-03 00:00:00 America/New_York", dateTimeFormatter);

And I get this error back:
org.threeten.bp.format.DateTimeParseException: Text '2012-06-03 00:00:00 America/New_York' could not be parsed: Invalid index 0, size is 0

It seems to work fine running Java 1.8.0_45 (See this stackoverflow post: http://stackoverflow.com/a/35420726/3113823)

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 :)

For example: Period.ofDays(7).minus(Period.ofDays(7))
Gives a period of 14 days, not zero.
The culprit may be the add operations within the minus method - the amounts to subtract aren't negated.

    return create(
            Jdk8Methods.safeAdd(years, amountToSubtract.years),
            Jdk8Methods.safeAdd(months, amountToSubtract.months),
            Jdk8Methods.safeAdd(days, amountToSubtract.days));

(added as ThreeTen/threeten#280 )

Working on an OLD system that we are enhancing with a lot of Time/Date/Timezone functionality. We thought JSR-310BP would be a good choice to simplify our migration to Java8 in the next year.

In local environment running Windows, Eclipse, TCServer, Java 1.7 we aren't seeing the issue.

However when we deploy to Linux TCServer 2.6.5 we get the issue when serializing ZonedDateTime to send back to the Window Swing client, Java 1.7

We are seeing the following exception in the stacktrace (more trace below)
java.net.SocketException: Broken Pipe
when attempting to use default serialization of a ZonedDateTime thru RMI.

Interestingly if we make the ZonedDateTime attribute transient and create our own readObject/writeObject to handle serialization it works fine. The writeObject() merely calls:
out.writeObject(theZonedDateTimeAttribute);

Any tips or suggestions would be appreciated!

David

More full stacktrace:

java.net.SocketException: Broken pipe
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
at java.net.SocketOutputStream.write(SocketOutputStream.java:153)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.write(BufferedOutputStream.java:126)
at java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1857)
at java.io.ObjectOutputStream$BlockDataOutputStream.setBlockDataMode(ObjectOutputStream.java:1766)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1185)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:346)
at java.util.ArrayList.writeObject(ArrayList.java:710)
at sun.reflect.GeneratedMethodAccessor115.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:975)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1480)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1528)
at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:438)

According to the specification (http://en.wikipedia.org/wiki/ISO_8601#Week_dates)
this line
localDate.get(WeekFields.ISO.weekOfYear())

should return '1' for Monday 29 December 2008, but it return '53'.

When using threetenbp in an OSGi environment (Eclipse RCP application) I have an error with version 1.0:

Missing requirement: org.threeten.bp 1.0.0 requires package sun.util.calendar but it could not be found.

There was no error with version 0.8.1.
It seems that you added "Import-Package: sun.util.calendar" in the manifest. I don't think you should, because the package is part of the JDK.

The method ZonedDateTime.now() calls ZoneRegion.ofId() and then reads data from disk, which takes approximately 400ms to 600ms on my Samsung S4 device, and seems to happen every time this method is called. I got this piece of information from the StrictMode facility in Android which can monitor and warn developers of disk operation on main (UI) thread.

This disk reading can introduce a significant lag if the application is doing UI transition at the same time, which can easily happen when a new Fragment is initializing itself while the NavigationalDrawer is sliding to close.

Is there any approach that can cache the content read from disk, so that it can be used safely on main thread?

It seems like the exception throwing implementation could just be removed, leaving the method abstract?

This is generated by the compiler and embedded in the jar but appears unused as far as I can tell. Is it the case that it is unused? Or am I missing something here?

Android 2.3 and later supports stand-alone text forms for months and days of weeks.
Also Android 4.3 and later supports narrow text forms.
These text forms can be acquired by using SimpleDateFormat with appropriate patterns.

To take advantage of these Android features we need to be able to set a custom implementation of DateTimeTextProvider as default.

Current implementation of DateTimeTextProvider.getInstance() returns a new instance every time. Is that intentional?

I'm trying to deserialise this class in Retrofit:

data class Measurement(val id: Long, val value: Float, val dateTime: LocalDateTime, val trashCanId: Long) : Parcelable {
companion object {
@JvmField val CREATOR: Parcelable.Creator = object : Parcelable.Creator {
override fun createFromParcel(source: Parcel): Measurement = Measurement(source)
override fun newArray(size: Int): Array<Measurement?> = arrayOfNulls(size)
}
}

constructor(source: Parcel) : this(source.readLong(), source.readFloat(), source.readSerializable() as LocalDateTime, source.readLong()) 

override fun describeContents() = 0 

override fun writeToParcel(dest: Parcel?, flags: Int) { 
    dest?.writeLong(id) 
    dest?.writeFloat(value) 
    dest?.writeSerializable(dateTime) 
    dest?.writeLong(trashCanId) 
} 

}
As you can see, I'm using LocalDateTime, it's from ThreeTen. Well, I receive this from my server

{
    "id": 1,
    "value": 50.6,
    "dateTime": {
      "hour": 2,
      "minute": 6,
      "second": 9,
      "nano": 0,
      "dayOfYear": 308,
      "dayOfWeek": "THURSDAY",
      "month": "NOVEMBER",
      "dayOfMonth": 3,
      "year": 2016,
      "monthValue": 11,
      "chronology": {
        "id": "ISO",
        "calendarType": "iso8601"
      }
    }
  }

Well, but my dateTime is always Null so I believe that Retrofit doesn't know how parse the Data, or am I missing something?

Is there any good workaround?

After looking into the issues we're having with the JSR 310 code in an OSGi environment, we believe they are due to the use of java.util.ServiceLoader and the assumption that classes are in the system classloader.

For example:

javax/time/zone/ZoneRulesProvider.java

    static {
//        ServiceLoader<ZoneRulesProvider> sl = ServiceLoader.load(ZoneRulesProvider.class, ClassLoader.getSystemClassLoader());
        List<ZoneRulesProvider> loaded = new ArrayList<>();
//        Iterator<ZoneRulesProvider> it = sl.iterator();
//        while (it.hasNext()) {
//            ZoneRulesProvider provider;
//            try {
//                provider = it.next();
//            } catch (ServiceConfigurationError ex) {
//                if (ex.getCause() instanceof SecurityException) {
//                    continue;  // ignore the security exception, try the next provider
//                }
//                throw ex;
//            }
//            registerProvider0(provider);
//        }
        ZoneRulesProvider provider = new TzdbZoneRulesProvider();
        registerProvider0(provider);
        // CopyOnWriteList could be slow if lots of providers and each added individually
        PROVIDERS.addAll(loaded);
    }

and

javax/time/zone/TzdbZoneRulesProvider.java

    public TzdbZoneRulesProvider() {
        super();
        if (load(/*ClassLoader.getSystemClassLoader()*/this.getClass().getClassLoader()) == false) {
            throw new ZoneRulesException("No time-zone rules found for 'TZDB'");
        }
    }

There are many sources of information about the limitations of the java.util.ServiceLoader under OSGi. In fact, the most recent revision of the OSGi R5 Enterprise specification describes a "ServiceLoader Mediator" which addresses those limitations. Unfortunately, the Equinox implementation of OSGi is based on the v4 spec and does not have the SL mediator.

Sorry if this is a false alarm, but is it intentional that https://github.com/ThreeTen/threetenbp/blob/master/src/main/java/org/threeten/bp/Instant.java#L492 never returns any value, and always throws an exception, either a DateTimeException or an UnsupportedTemporalTypeException?

If this is intended, maybe it would help to add a short code comment?

how to exclude the TZDB.dat , because i use another way to load it

IIUIC, the LocalDate.ofEpochDay() uses UTC time zone for computing the localdate and not the system default timezone, nor does it allow a time zone to be provided.

This is probably an oversight either in the thinking (no days are not time zone dependent - wrong) or oversight in documenting what is exactly happening.

I am simply suggesting that the Javadoc is updated to state that UTC is used, which could go into a patch release.

It seems that Instant.Parse is not working. I am trying to use it but it fails. I copied the argument from the javadoc (here http://threeten.github.io/threetenbp/apidocs/org/threeten/bp/Instant.html#parse(java.lang.CharSequence) but it says that is an illegal format.

Code:

 Instant instant = Instant.parse("2007-12-03T10:15:30:00");

Exception:

org.threeten.bp.format.DateTimeParseException: Text '2007-12-03T10:15:30:00' could not be parsed at index 19
    at org.threeten.bp.format.DateTimeFormatter.parseToBuilder(DateTimeFormatter.java:1319)
    at org.threeten.bp.format.DateTimeFormatter.parse(DateTimeFormatter.java:1223)
    at org.threeten.bp.Instant.parse(Instant.java:339)
    at org.modelinglab.ocl.ext.time.classes.InstantDate.testParse(InstantDate.java:19)

Could it be a problem with the codification?

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

I'm using ThreeTen on Android via ThreeTenABP. I'm trying to format a ZonedDateTime as Tuesday, March 19. But I'm only ending up with Tue, 3 19. I believe this is different than #50. It's happening on all devices, and the actual date is correct, just the formatting is wrong.

I'm pretty sure I'm following the formatting string guidelines correctly.

DateTimeFormatter dateFormat = DateTimeFormatter.ofPattern("EEEE, MMMM d");
String dateString = zonedDateTime.format(dateFormat);

The bizarre part is that when I unit test this code it works fine, but running on an actual Android device truncates day of the week and uses integer for month.

The following simple test shows IST time zone is supported by java7 and not supported by threetenbp :(
https://gist.github.com/solomax/818844adec1e8538123b

Stacktrace like this:

org.threeten.bp.zone.ZoneRulesException: Unknown time-zone ID: IST
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)

Can it be addressed please :)

The test fails because a duration of 2h is found for Antarctica/Troll TZ, which seem available in IBM JVM 7.1, but not in Oracle or even IBM JVM 7.0.

While it looks like a joke, there is really a TZ for Antarctica/Troll which looks like no other: http://mm.icann.org/pipermail/tz/2014-March/020705.html

Probably a big ask, but would be nice to make the initialization process work in both java or android world, while maintaining efficiency.

see sister issue: #45

Following test case is failing using the 0.8.1 version of the backport

public class SimpleTest  extends TestCase 
{
    public void testLocalDateWith5DigitYear()
    {
        LocalDate date = LocalDate.parse("10000-12-31",  DateTimeFormatter.ISO_LOCAL_DATE);
        assertEquals(10000, date.getYear());
    }

}

I get the following exception:
org.threeten.bp.format.DateTimeParseException: Text '10000-12-31' could not be parsed at index 0

The javadoc for DateTimeFormatter.ISO_LOCAL_DATE states that it supports "Four digits or more for the year".

Is this is a bug? Any workarounds I can use in the meantime?

Thanks

Abhinav Rau