threeten/threetenbp

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

ThreeTen backport project

JSR-310 provides a new date and time library for Java SE 8. This project is the backport to Java SE 6 and 7.

See the main home page of the project.

The backport is NOT an implementation of JSR-310, as that would require jumping through lots of unnecessary hoops. Instead, this is a simple backport intended to allow users to quickly use the JSR-310 API on Java SE 6 and 7. The backport should be referred to using the "ThreeTen" name.

Active development on JSR-310 is at OpenJDK:

This GitHub repository is a fork of that originally used to create JSR-310. That repository used the same BSD-3-Clause license as this repository.

Issues about the backport should be reported here at GitHub. Pull requests and issues will only be considered so far as matching the behaviour of the real Java SE 8. Additional requested features will be rejected.

Building

This project builds using maven.

Time-zone data

The time-zone database is stored as a pre-compiled dat file that is included in the built jar. The version of the time-zone data used is stored within the dat file (near the start). Updating the time-zone database involves using the TzdbZoneRulesCompiler class and re-compiling the jar file. An automated CI job should help keep the time-zone data up to date.

FAQs

1. What version of Java SE 8 does this project map to? This project currently maps to the contents of release Java SE 8u20.

2. Will the backport be kept up to date? There are no plans for further releases. However if security issues or bugs are found, or pull requests received then a release may occur.

3. Is this project derived from OpenJDK? No. This project is derived from the Reference Implementation previously hosted on GitHub. That project had a BSD license, which has been preserved here. Thus, this project is a fork of the original code before entry to OpenJDK.

Releases

Available in the Maven Central repository

Support

Please use Stack Overflow for general usage questions. GitHub issues and pull requests should be used when you want to help advance the project. Commercial support is available via the Tidelift subscription.

Note that pull requests and issues will only be considered so far as matching the behaviour of Java SE releases. Additional requested features will be rejected.

Pull requests must not be copied from the JDK, because the GPL license is incompatible with the BSD license used here.

To report a security vulnerability, please use the Tidelift security contact. Tidelift will coordinate the fix and disclosure.

Release process

• Update version (index.md, changes.xml - checking tzdb version)
• Commit and push
• Run mvn clean release:clean release:prepare release:perform on Java 11
• Website will be built and released by GitHub Actions

threetenbp's Issues

org.threeten.bp.zone.ZoneRulesException: Unknown time-zone ID: Asia/Hanoi

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)

LocalDate.ofEpochDay may return a wrong result

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.

Timestamp/Time/Date is currently unsuitable for LocalDateTime/LocalDate/LocalTime

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.

Make the time zone jar data loading pluggable to avoid Android performance problems

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.

Always reading timezone data from disk may impact performance on Android

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?

Generic non-location format for time zones unavailable?

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?

It seems that Instant#parse is not working

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?

Date formatting fails on some Android devices

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.

Inconsistent behaviour with ChronoField.MONTH_OF_YEAR parsing

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].

Utility class to convert to/from java.util.Date, GregorianCalendar, SQL, XML types

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.

LocalDate.ofEpochDate() should specify the TimeZone used

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.

Support for (single letter) military time zone ids other than Z

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

DateTimeFormatter not properly formatting month and day of week string

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.

IST timezone is not supported

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

Unknown time-zone ID: US/Pacific-New

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

Backport bugs from OpenJDK

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.

1.3.5 contains 2 jars with timezone files

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.

Create qualified artifact without timezone data bundled.

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

How to deserialize ThreeTen LocalDateTime in Retrofit?

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?

Crash with ART runtime on Android Lollipop

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

Islamic date is not same as Threeten

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

java.util.spi.LocaleServiceProvider prevents threetenbp to be used on Google App Engine

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?

Wrong documentation of public <T> T DateTimeFormatter.parse(CharSequence text, TemporalQuery<T> type)

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)

Backport to JDK 6

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

Decouple time zone loading to provide pure java support

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

how to exclude the TZDB.dat

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

RMI Serialization Issue?

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)

Crash in StandardZoneRules#nextTransition() when no historic transitions are present.

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 cannot parse TimeZones

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)

Incorrect polish FULL_STANDALONE months name

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ń

Allow custom DateTimeTextProvider to be set as default

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?

Does not work on Android L

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

I removed LocaleServiceProvider implementations, it worked.
emonkak@eb3d777

ZonedDateTime toString is broken after deserialization

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".

Cannot use JSR-310 within an OSGi Runtime

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.

Backport of fix for bug 8033662

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

Consider TzdbZoneRulesProvider InputStream factory/ctor?

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.

Suspicios-looking code in Instant

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?

Wrong OSGi Import-Package

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.

Period.minus(Period) broken

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 )

The ISO week-numbering is wrong for the last days of a year

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'.

TimeZoneTest.testDuration fails when using IBM JVM 7.1 because of "Antarctica/Troll" TZ

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

no-tzdb should exclude ServiceLoader code from ZoneRulesProvider

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

Cannot parse time offsets in the form ±[hh][mm] or ±[hh]

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

LeapSecondRules.dat unused?

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?

Chronology#resolveDate claims "ThreeTen Backport does not support resolveDate", but all chronologies implement it

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

Possible license violations?

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

LocalDate.parse("10000-12-31", DateTimeFormatter.ISO_LOCAL_DATE) throws DateTimeParseException

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

No time-zone data files registered

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.

ZonedDateTime.parse throws exception during property testing.

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 '[phone]T12: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 = "[phone]T12:10:32.251652071-01:00[Etc/GMT+1]"
bad: String = [phone]T12:10:32.251652071-01:00[Etc/GMT+1]

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

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

Javadoc for Duration wrong

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

Also false for toDays()