threeten / threeten-extra

Provides additional date-time classes that complement those in JDK 8

Former home of the ThreeTen/JSR-310 project

JSR-310 is a project under the Java Community Process to provide a modern date and time library for the JDK. ThreeTen is the name of the Reference Implementation used to develop the specification.

Status

This GitHub project is currently dormant, as active development of JSR-310 has moved to OpenJDK to integrate with JDK1.8:

• Project: http://openjdk.java.net/projects/threeten/
• Code: http://hg.openjdk.java.net/threeten/threeten/jdk
• Mailing list: http://mail.openjdk.java.net/mailman/listinfo/threeten-dev

The active issue tracker is still located here at GitHub:

• Issues: https://github.com/ThreeTen/threeten/issues

A backport of the API, but not the JSR, has been provided for JDK1.7 users: https://github.com/ThreeTen/threetenbp This is available in the Maven Central repository and uses the ThreeTen name.

A helpful home page has been created, where some documentation is being developed (applicable to JSR-310 and the ThreeTen backport). http://threeten.github.com/

History

As a long running project, the project has moved location down the years.

Source code history

This GitHub project was the home of the source code for a period from 2011-06-24 to 2012-12-04.

The initial commit to OpenJDK occurred on 2012-11-09: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b74a5a99159a using commit from GitHub: https://github.com/ThreeTen/threeten/commits/b9566e443b6279f7f1abe675ff012575fb3018f3 This commit was made by scolebourne to establish IP transfer to OpenJDK.

Commits then occurred on both GitHub (scolebourne) and OpenJDK (rriggs, sherman) for the period from 2012-11-09 to 2012-12-04, a total of 136 GitHub commits. Here is an example of a commit (the first one) that was ported manually: https://github.com/ThreeTen/threeten/commit/1eb175e448fd77fdd1971c7d3266199aa4bba89c http://hg.openjdk.java.net/threeten/threeten/jdk/rev/4692637fbb48 Note that the porting changes the author (from scolebourne to rriggs).

The last commit to this repository that was ported to OpenJDK was on 2012-12-04: https://github.com/ThreeTen/threeten/commit/280f25a00d96df7943b89265ece46e593b823926 http://hg.openjdk.java.net/threeten/threeten/jdk/rev/4cc0f3c099e0

Prior to being hosted at GitHub, the source code was hosted at Sourceforge. http://threeten.sourceforge.net/ http://sourceforge.net/projects/threeten/ The VCS used was git from 2011-06-24 to 2011-06-24 (part of migrating to GitHub): http://sourceforge.net/p/threeten/code The VCS was svn up from 2010-12-24 to 2011-06-10: http://sourceforge.net/p/threeten/svn/1497/tree/ Last commit at Sourceforge became this commit at GitHub: https://github.com/ThreeTen/threeten/commit/83f2a944dc8f0ab4fb240132977f56958aede9be

Prior to being hosted as Sourceforge, the source code was hosted at Java.net. http://java.net/projects/jsr-310 The VCS was svn: http://java.net/projects/jsr-310/sources/svn/show Last commit at Java.net: http://java.net/projects/jsr-310/sources/svn/revision/1336 became this commit at Sourceforge: http://sourceforge.net/p/threeten/svn/1281/tree/

No source code commit history was lost during the move from Java.net to Sourceforge to GitHub. All source code commit history was lost in the move to OpenJDK.

Mailing list history

Currently at OpenJDK: http://mail.openjdk.java.net/mailman/listinfo/threeten-dev

Previously at Sourceforge: http://sourceforge.net/mailarchive/forum.php?forum_name=threeten-develop

Prior to that at Java.net http://java.net/projects/jsr-310/lists/dev/archive

Summary

Location	VCS	Dates
Java.net	svn	from inception to 2010-12-24
Sourceforge	svn	from 2010-12-24 to 2011-06-24
Sourceforge	git	from 2011-06-24 to 2011-06-24
GitHub	git	from 2011-06-24 to 2012-12-04
OpenJDK	hg	from 2012-12-04 onwards

threeten-extra's Issues

YearWeek.atDay() throws an exception if resulting LocalDate is in next year.

Example: YearWeek.of(2016, 52).atDay(SUNDAY). It tries to create LocalDate with year 2016 and day-of-year 367 and explodes. Date-is-in-previous-year case seems to be supported.

Manifest OSGI properties mandate Java 9+

This means I can't use it in a container running on Java 8.

The manifest specifies:

Bundle-Version: 1.3.2
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=9.0))"

Add Discordian calendar system

Add the amusing Discordian calendar system

Add PeriodDuration

New class PeriodDuration that combines Period and Duration.

Add Hours/Weeks classes similar to joda-time

Would it be possible to add Hours/Weeks classes similar to joda-time? or we should simply use Duration/Period instead?

More frequent releases

Hi Stephen,

Please consider making more frequent releases (ideally once a month). The last release is almost 10 months old.

Support Allen's interval logic

Consider adding additional methods to Interval to support the operations described here:
https://en.wikipedia.org/wiki/Allen's_interval_algebra
(A few are already supported but named differently)

AbstractDate.with(ChronoField.Era, long newValue) ignores the new value.

AbstractDate.with(ChronoField.Era, long newValue) ignores whatever newValue happens to be, and flips to the other era (assuming a two-era calendar).
The minimal example JulianDate.of(1, 1, 1).with(ChronoField.ERA, 1).getLong(ChronoField.ERA) thus returns 0, which is obviously not correct.

Release 0.10?

Hi Stephen,

any chances we see a 0.10 release soon? Really looking forward to add threeten-extra as a "real" maven dependency.

Interval constructors don't support Instant.MIN or Instant.MAX

I was curious about using unbounded Intervals. According to the source code, an Instant is "unbounded" if:

• start.equals(Instant.MIN)
• end.equals(Instant.MAX)

However, Interval.parse() chokes if passed either Instant.MIN or Instant.MAX:
Interval.parse( "-1000000000-01-01T00:00:00Z/2008-05-11T15:30:00Z" )

java.time.format.DateTimeParseException: Text '-1000000000-01-01T00:00:00Z' could not be parsed: Invalid value for Year (valid values -999999999 - 999999999): -1000000000

Interval.parse( "2007-03-01T13:00:00Z/[phone]T23:59:59.999999999Z" )

java.time.format.DateTimeParseException: Text '[phone]T23:59:59.999999999Z' could not be parsed: Invalid value for Year (valid values -999999999 - 999999999): 1000000000

I can create an unbounded Interval if I try something sneaky like:

Interval interval = Interval.ALL.withStart( Instant.parse( "2007-03-01T13:00:00Z" ) );

... but Interval.parse() still fails to deserialize Instant.MIN or Instant.MAX:
Interval.parse( interval.toString() );

Exception in thread "main" java.time.format.DateTimeParseException: Text '[phone]T23:59:59.999999999Z' could not be parsed: Invalid value for Year (valid values -999999999 - 999999999): 1000000000

Is there a way to support parsing MIN & MAX? I need to serialize/deserialize unbounded Intervals.

Interval.overlap

I think it'd be great to have a function to calculate the actual overlap between two Intervals. I've needed this wherever I used Interval. Would love to submit a patch if it can make to the library!

Julian calendar system

Implement Julian calendar system.

'YearQuarter' documented as being ISO 8601, but that standard has no quarters.

The class documentation for YearQuarter claims to be:

A year-quarter in the ISO-8601 calendar system

But the ISO 8601 standard does not appear to have any mention of "quarter". In drafts I have seen for ISO 8601:1998 and ISO 8601:2004(E), neither PDF document contains the word "quarter" or "Q1". The Wikipedia page for ISO 8601 makes no mention of quarters. The text of RFC 3339 (a profile of ISO 8601) makes no mention of "quarter".

More importantly, the YearQuarter class defines quarter by the calendar weeks/months with January 1 starting Q1, April 1 starting Q2, and so on. That, in and of itself, is fine. But, when mentioning ISO 8601, the standard’s definition of weeks springs to mind. The reader may well think that an ISO 8601 quarter might align with those standard weeks rather than calendar weeks.

I suggest the class documentation be edited to:

• Clarify whatever was meant by the mentions of ISO 8601. (I am not clear myself)
• Explicitly define quarters as being calendar-based (January 1, April 1, July 1, October 1).

Better integration with XML date/time classes

Provide tools to integrate with the XML classes.

Duration.multipliedBy(double)

I am attempting to reimplement https://developers.google.com/api-client-library/java/google-http-java-client/reference/1.20.0/com/google/api/client/util/ExponentialBackOff in terms of Durations. At some point, I need to multiply a Duration by a double multiplier.

Is there a reason Duration.multipliedBy() only takes an integer? Or can a double variant be added?

extras for theeten BP?

I really thought that this project was something that compliments the threeten backport rather then java 8 time. is there a backport compatible version of this project? I would imagine its not super complicated to convert this to use the bp classes which already suppose to mimic the new java8 time libs.

An adjustable clock

I think an adjustable java.time.Clock — one that lets users change which Instant is reported by clock.instant() at will — would be a useful addition to threeten-extra.

Use case

Short version: I'd use it for testing.

Long version:

I've started following the best practices described in Clock's javadocs, avoiding methods like System.currentTimeMillis() and Instant.now() in favor of asking a Clock instance for the current time. The clock is managed with dependency injection.

In production I use Clock.system(...). In tests, none of the JDK-provided clocks give me quite what I want so I've had to implement my own.

When testing some clock-sensitive behavior of my application, I want to:

1. Set up the relevant components.
2. Do some clock-sensitive operation with the components.
3. Adjust the clock to simulate the passage of time.
4. Do another clock-sensitive operation and verify the result.

For example:

1. Set up the subscription engine.
2. Start a new monthly subscription.
3. Fast forward one month.
4. Verify that payment is due for the new subscription.

These components accept the clock as a constructor parameter (in step 1) and store it in a private final field. When adjusting the clock (in step 3), I really want that to be a simple one-liner in my test code.

I think the best way to approach that problem is with a new kind of java.time.Clock, which is the subject of this feature request.

These alternatives seem undesirable:

• Recreate all of my components so that I can provide a new clock.
• Make the clock fields of my components non-final so that I can assign them a new clock.
• Avoid injecting or storing a clock directly in any of my components, use something like a Supplier<Clock> instead, and have the components call clockSupplier.get() (by whatever name) whenever they need the clock.
• Use a mocking library in tests to create a fake clock, and mock each method of the fake clock that the components happen to use.

Requirements

• Essential: Construct a new clock with a given instant and zone.
• Essential: Replace the instant of an existing clock with a new instant.
• Nice to have: Atomically update the instant of an existing clock given its current instant.
• Nice to have: Speak in terms of local date-times instead of absolute instants.

Proposed API

import java.io.Serializable;
import java.time.Clock;
import java.time.Instant;
import java.time.LocalDateTime;
import java.time.ZoneId;
import java.util.function.UnaryOperator;

public final class AdjustableClock extends Clock implements Serializable {

  public static AdjustableClock atInstant(Instant instant, ZoneId zone);
  public static AdjustableClock atDateTime(LocalDateTime dateTime, ZoneId zone);

  public void setInstant(Instant instant);
  public void setDateTime(LocalDateTime dateTime);
  public void adjustInstant(UnaryOperator<Instant> adjustmentFunction);
  public void adjustDateTime(UnaryOperator<LocalDateTime> adjustmentFunction);

  @Override public AdjustableClock withZone(ZoneId zone);
  @Override public ZoneId getZone();
  @Override public Instant instant();
  @Override public boolean equals(Object obj);
  @Override public int hashCode();
  @Override public String toString();

}

---

Your thoughts?

Exception thrown by Math.floorDiv for version 1.3

Once we updated to the latest threeten-extra (1.3) we are getting the following exception:

Caused by: java.lang.NoSuchMethodError: java.lang.Math.floorDiv(JI)J
	at org.threeten.extra.chrono.JulianDate.toEpochDay(JulianDate.java:461)
	at org.threeten.extra.chrono.AbstractDate.getLong(AbstractDate.java:136)
	at org.threeten.extra.chrono.JulianDate.getLong(JulianDate.java:74)

-- End of 310-extra stack trace.

	at java.time.temporal.TemporalQueries.lambda$static$5(TemporalQueries.java:383)
	at java.time.chrono.ChronoLocalDate.query(ChronoLocalDate.java:519)
	at java.time.LocalDate.from(LocalDate.java:365)

	at de.jollyday.util.CalendarUtil.getJulianEasterSunday(CalendarUtil.java:144)
	at de.jollyday.util.CalendarUtil.getEasterSunday(CalendarUtil.java:120)
	at de.jollyday.parser.AbstractHolidayParser.getEasterSunday(AbstractHolidayParser.java:185)
	at de.jollyday.parser.impl.ChristianHolidayParser.parse(ChristianHolidayParser.java:45)
	at de.jollyday.impl.DefaultHolidayManager.parseHolidays(DefaultHolidayManager.java:153)
	at de.jollyday.impl.DefaultHolidayManager.getHolidays(DefaultHolidayManager.java:109)
	at de.jollyday.impl.DefaultHolidayManager.getHolidays(DefaultHolidayManager.java:69)

TemporalField for packed time

See this question. A packed field would support integers like 0 to 59 as minutes, 100 as 01:00, 130 as 01:30 and so on. Similar field for seconds would also makes sense.

Add Ethiopic calendar system

The Ethiopic calendar system.

Add additional support for years in Months

Include support for years in Months, just like Days supports weeks.

toPeriod()'s name in Hours class does not match convention

Looking at methods converting to Duration from Interval, Hours, Minutes, Seconds etc. it looks that the one in Hours class has invalid name: toPeriod() while all others have toDuration().

Support for the date part of an ISO 8601 time interval

I'm not really sure if this is a bug or if this is the expected behavior. I try to parse the ISO 8601 time interval "2007-03-01T13:00:00Z/P1Y2M10DT2H30M" as noted in the Wikepedia page. This is not possible with the current Interval implementation, because it doesn't support the date part of the interval. If I remove the date part, then it works as expected.

Interval.parse("2007-03-01T13:00:00Z/P1Y2M10DT2H30M") // Fails
Interval.parse("2007-03-01T13:00:00Z/PT2H30M") // Works

It seems that the issue comes from the fact that the java.time.Duration class cannot parse this format. It seems that the current Java implementations uses two classes to represent the ISO 8601 duration format. The java.time.Period class can parse the date part and the java.time.Duration class can parse the time part.

I'm not really sure if this is wrong documented on the Wikipedia page, or if this is an issue in the library. Anyway, the org.joda.time.Interval does parse the string with the date part "2007-03-01T13:00:00Z/P1Y2M10DT2H30M".

Interval.Parse and ISO 8601 time intervals

It appears only <start>/<end> is supported whilst Wikipedia lists these:

<start>/<duration>
<duration>/<end>
<duration>

And Joda Time supports:

<start>/<duration>
<duration>/<end>

The most flexible addition would be <start>/<duration>.

Interval around time/instant

What I'm implementing for myself is a factory method for intervals of a certain duration symmetrically surrounding an instant; e.g., to check if something arrived within five minutes of noon on some day. Something like

Interval.surrounding(Instant center, Duration length)

that does the division by two, subtraction from the instant, and construction of the interval. Is there a clean way to do this, or does it make sense to add as a static factory in some form (perhaps with better names or without the division by two - e.g. specifying the half-length)?

Thanks for a great library!

Symmetry010 handles ALIGNED_DAY_OF_WEEK_IN_MONTH incorrectly, claims each month starts on a monday

The Symmetry010 date and chronology claim every month starts on a Monday:

Week day - every month starts on a Monday. There are no days outside of the week or month.

This is false; every quarter (and year) starts on a Monday.
I haven't looked to see if anything other than the documentation would need to be adjusted.

@catull

Extend conversion between amount types

Allow Years to accept decades, centuries, milliennia and full multiples of quarters and months. And so on.

TestYearWeek#test_parse_CharSequenceDateTimeFormatter fails

'mvn test' fails in master with

Running TestSuite
Configuring TestNG with: TestNG652Configurator
Tests run: 9139, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.799 sec <<< FAILURE! - in TestSuite
test_parse_CharSequenceDateTimeFormatter(org.threeten.extra.TestYearWeek) Time elapsed: 0.014 sec <<< FAILURE!
java.time.format.DateTimeParseException: Text 'Mon W1 2015' could not be parsed at index 2
at java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1947)
at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1849)
at org.threeten.extra.YearWeek.parse(YearWeek.java:264)
at org.threeten.extra.TestYearWeek.test_parse_CharSequenceDateTimeFormatter(TestYearWeek.java:617)

Is this specific to MacOS X 10.10.3 with Oracle JDK 1.8.0_45, maven 3.3.1 ?
The same effect manifests when using Azul's OpenJDK, both zulu 1.8.0_20 [1] and zulu 1.8.0_45 [2].

[1] http://cdn.azulsystems.com/zulu/2014-09-8.3-bin/zulu1.8.0_20-8.3.0.4-macosx.zip
[2] http://cdn.azulsystems.com/zulu/2015-04-8.7-bin/zulu1.8.0_45-8.7.0.5-macosx.zip

JulianDateTime ?

Is there any future plan of something like JulianDateTime ? which implements ChronoLocalDateTime<JulianDate>

Thanks.

This is my premature work , but I don't know too much about ChronoLocalDateTime ... Not sure how to finish this work.

public class JulianDateTime implements Serializable {

  private final JulianDate date;
  private final LocalTime time;


  private JulianDateTime(JulianDate date, LocalTime time) {
    this.date = date;
    this.time = time;
  }

  /**
   * @param year maybe <= 0
   */
  public static JulianDateTime of(int year, int month, int dayOfMonth, int hour, int minute , double second) {
    JulianDate date = JulianDate.of(year , month , dayOfMonth);

    int secs = (int) second;
    int nano = (int) ((second - secs)* 1_000_000_000);
    LocalTime time = LocalTime.of(hour , minute , secs , nano);
    return new JulianDateTime(date , time);
  }

  /**
   * @param year maybe <= 0
   */
  public static JulianDateTime of(int year, int month, int dayOfMonth, int hour, int minute) {
    return of(year , month , dayOfMonth , hour , minute , 0);
  }

  /**
   * @param year maybe <= 0
   */
  public static JulianDateTime of(int year, Month month, int dayOfMonth, int hour, int minute) {
    return of(year , month.getValue() , dayOfMonth , hour , minute , 0);
  }

  public int getProlepticYear() {
    return date.get(YEAR);
  }

  /** must be >= 0 */
  public int getYear() {
    return date.get(YEAR_OF_ERA);
  }

  public int getMonth() {
    return date.get(MONTH_OF_YEAR);
  }

  public int getDayOfMonth() {
    return date.get(DAY_OF_MONTH);
  }

  public int getHour() {
    return time.getHour();
  }

  public int getMinute() {
    return time.getMinute();
  }

  public double getSecond() {
    return time.getSecond() + (time.getNano() / 1_000_000_000.0);
  }

  public JulianDate toLocalDate() {
    return date;
  }

  public LocalTime toLocalTime() {
    return time;
  }

PeriodFormatter

http://blog.joda.org/2014/11/converting-from-joda-time-to-javatime.html says that PeriodFormatter is not included in java.time. Can this be added to threeten-extra?

Parsing support from P1D to Hours, Minutes and Seconds?

There is probably an inconsistency between parsing from ISO8601 Period's day value to Hours, Minutes, Seconds and converting from Period objects.

Those methods throw error: Text cannot be parsed to a ...

Seconds.parse("P1D");
Minutes.parse("P1D");
Hours.parse("P1D");

Those methods work fine (for Minutes and Hours as well).

Duration.parse("P1D");
Seconds.from(Period.parse("P1D"));
Seconds.from(Days.of(1));

It is even possible to Seconds.from(Weeks.ONE) but in this case Duration.from(Weeks.ONE) throws error.
I am unsure about this issue, please share your thoughts.

Support to try to parse String using multiple patterns

Not sure what would be the best way to achieve that but I think it would be useful to be possible to test different patterns to parse a String that represents a date/datetime in an unknown format.

I tried the following with no success:

DateTimeFormatterBuilder builder = new DateTimeFormatterBuilder();
//simplified for readability
String[] patterns = {"yyyy-MM-dd","yyyy-MM-dd HH:mm:ss","yyyy-MM-dd'T'HH:mm:ss"};
for(String pattern : patterns) {
    builder.appendOptional(DateTimeFormatter.ofPattern(pattern));
}
DateTimeFormatter dtFormatter = builder.toFormatter();
TemporalAccessor ta = dtFormatter.parseBest(input, LocalDateTime.FROM, LocalDate.FROM,);

It seems to work if I only provide patterns that are very similar otherwise, I have a DateTimeParseException: could not be parsed, unparsed text found at index ....

What I have in mind is something similar to Apache DateUtils.parseDate().

Maybe this is out-of-scope for threetenbp so that why I am reporting it in threeten-extra.

Please let me know if my test above is wrong and/or there is more documentation about how this could be implemented.

empty interval does not abut a non-empty interval

Interval.abuts(Interval other) does not return true when other is empty but does equal the start/end value. The docs state it should not be equal when both are empty, but not when only one is empty.

Libraries importing Threeten-extra failing in OSGI-Environments with a 1.8 JRE

We use jollyday 0.5.4 in our Apache-Camel Routes on an Apache Servicemix/Karaf, this dependency requires threeten-extra 1.3.2 and thus the whole application cannot be build in an osgi/java8 environment without working around this issue.

Every library importing Threeten-Extra 1.3.2 will fail in an OSGI environment running on Java-1.8.
The issue itself seems to have been fixed a while ago #92 #94, but a fixed version is not available on maven central yet.

TemporalAmount classes for Hours, Minutes and Seconds

Hello,
Are there any reasons for not having Amount classes for Hours, Minutes and Seconds?

Add additional support for weeks in Days

The Period class allows parsing week patterns and provides ofWeeks factory. Extend Days in a similar way.

Fix Java 9 to work on module path

While the previous release had a module-info.class file it did not work properly on the module path. The chronologies were not registered in the module-info and the leap seconds text file was not loaded correctly.

Note that this change is incompatible. Previously, applications could add LeapSeconds.txt to their jar file and have it automatically picked up. Now, an API call to UtcRules must be made instead. Thank the design of JPMS for this.

YearWeek.atDay

I think I found a bug, in YearWeek.atDay, when the days in the YearWeek overflow into the new year.

Test Case:

@Test
public void testAtDay() {
    YearWeek yearWeek = YearWeek.of(2015, 53);

    LocalDate date;

    date = yearWeek.atDay(DayOfWeek.MONDAY);
    assertEquals(LocalDate.of(2015, 12, 28), date);   // OK!

    date = yearWeek.atDay(DayOfWeek.SUNDAY);
    assertEquals(LocalDate.of(2016, 1, 2), date);   // ERROR: java.time.DateTimeException: Invalid value for DayOfYear (valid values 1 - 365/366): 368
}

From looking at YearWeek.atDay it seems that the overflow into the new year is simply not handled (while the reverse is).

I believe the code should be changed to the following:

public LocalDate atDay(DayOfWeek dayOfWeek) {
    Objects.requireNonNull(dayOfWeek, "dayOfWeek");
    int correction = LocalDate.of(year, 1, 4).getDayOfWeek().getValue() + 3;
    int dayOfYear = week * 7 + dayOfWeek.getValue() - correction;
    if (dayOfYear < 0) {
        int daysOfPreviousYear = Year.isLeap(year - 1) ? 366 : 365;
        return LocalDate.ofYearDay(year - 1, daysOfPreviousYear + dayOfYear);
    } else if ((Year.isLeap(year) && dayOfYear > 366) || (dayOfYear > 365)) {
        int daysOfPreviousYear = Year.isLeap(year - 1) ? 366 : 365;
        return LocalDate.ofYearDay(year + 1, dayOfYear - daysOfPreviousYear - 1);
    } else {
        return LocalDate.ofYearDay(year, dayOfYear);
    }
}

Add British Cutover calendar system

Add a calendar system modelling the British Julian-Gregorian cutover on 1752-09-14 (ISO).

Why doesn't LocalDateTime have plus/minusMilliseconds()?

Out of curiosity, why does LocalDateTime have plus/minus hours, minutes, second and even nanoseconds, but not milliseconds? Is there a technical reason for this? Can it be added?

Yes, I am familiar with plus(long amountToAdd, TemporalUnit unit) but I'm wondering why all other units have dedicated methods and milliseconds does not.

Interval#parse(String) not working with time zones

Calling Interval#parse(String) with an ISO-8601 interval consisting of start and end, both specifying a timezone, a DateTimeParseException gets thrown. Example string:

2016-06-15T15:44:57+02:00/2016-06-29T16:08:41+02:00

joda-time's Interval implementation parses this string correctly. Is this behavior intended?

Provide ability to convert amounts between units

Provide a method that can convert amounts of time between different units. Will only work for JDK units in ISO.

Add `Interval` class similar to Joda-Time

I might have missed it, but neither Java 8 nor ThreeTen-Extra seem to include the Interval class from Joda time.

Is it going to be ported to one or the other? If not, what is the rationale for leaving it out?

Thanks.

Fix assertEquals and assertSame parameters order

Most of assertEquals and assertSame calls uses wrong parameters order. One of many below.

threeten-extra/src/test/java/org/threeten/extra/TestDays.java

Line 99 in 5955c0d

assertEquals(Days.of(0).getAmount(), 0);

It would be nice to fix this. I'll open PR very soon.

Support open Intervals

We have a lot of time interval queries in our system ("find data between x and y"). We'd like to formulate our queries with Interval objects.

However, sometimes we have queries with open intervals (i.e. "all data before y" or "all data after x"). Instead of creating new query methods we'd rather just pass in an open interval [,y] or [x,].

This is currently not possible, because creation of Interval objects does not permit to specify null boundaries.

French Republican Calendar

Hi,

I'd like to implement the French Republican calendar system.
The computation seems relatively feasible, but the problem is I don't know where to start. I'm not sure which classes/interfaces I should extend/implement.
ChronoLocalDate, org.threeten.extra.chrono.AbstractDate, LocalDate, ... ?
AbstractChronology, Chronology, ... ?
Can someone spare me the digging analysis ?

Thanks a lot.

YearWeek.plusWeek(int)

I try to get an YearWeek object representing the next week from now.
And I could not find a simple and convenient way.

I would have expected something like that:
YearWeek.now().plusWeeks(1)

Interval parsing should imply end offset

Interval parsing in ISO-8601 is allowed to infer the end offset from the start offset. Support this.

Ability to convert TimeUnit to ChronoUnit

Following up on http://stackoverflow.com/q/26581708/14731 we need a way to convert a TimeUnit to a ChronoUnit, for legacy APIs.

YearWeek?

I am missing a YearWeek class in JSR310. We made a custom class. Am I the only one with this issues? Anyone interested in a pull request?