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.

Every java.time.Clock also contains a time zone, and it can be freely used to produce zone-dependent values; as in LocalDate.now(clock). However, we've found that most users really just want zoneless Instants (the zone component usually comes from the user session, not the server).

Inside of Google we have a TimeSource interface, that looks like this:

public interface TimeSource {

  static TimeSource system() { ... }

  Instant now();

  default LocalDateTime now(ZoneId zoneId) { ... }

  default LocalDate today(ZoneId zoneId) { ... }

  default Clock asClock(ZoneId zoneId) { ... }
}

We strongly recommend its use over java.time.Clock, and its usage outnumbers Clock by 8x at this point.

We'd like to contribute this to threeten-extra, but a few obstacles:

1. we now have 30k+ references to our TimeSource, which makes migration very difficult (even for something as simple as a package/class rename).

2. threeten-extra already has a TimeSource interface in org.threeten.extra.scale. That interface is nearly what we want, minus the UtcInstant and TaiInstant-returning methods. Do you see any path forward for harmonizing these interfaces? What are the stability guarantees for threeten-extra?

Thanks, -Kurt (on behalf of Google's "GoodTime" team)

I guess that the main reason for blurring distinction between [*, LocalDate.MAX) and [*, +∞) was (1) inability to construct ranges containing LocalDate.MAX (that's my impression after following #53 discussion). The other reason I see is (2) presence of LocalDateRange.ofClosed which is the only possible way to (at least try to) create [*, LocalDate.MAX].

Although fix for #53, more or less, resolved problem with (1), it introduced new problems instead. I'll try to show this later.

As a side note... One may think that using [a, b] instead of [a, b) could be a good solution for (1) and (2) - although not being so convenient to implement, but that's another story. [a, b] would indeed solve (1) and (2), but at the same time it would introduce almost the same problem with toString. How would you stringify [LocalDate.MIN, LocalDate.MAX]? Would you consider "-999999999-01-01/+1000000000-01-01" legal despite "+1000000000-01-01" being out of domain? On the other hand, using "-999999999-01-01/+999999999-12-31" would make [LocalDate.MIN, LocalDate.MAX] indistinguishable from [LocalDate.MIN, LocalDate.MAX). This seems like some kind of vicious circle. Finally, with [a, b] you couldn't represent empty ranges.

To summarize: with [a, b) and no LocalDateRange.ofClosed, there would be just one problem: (1) inability to construct ranges containing LocalDate.MAX. I believe that making LocalDate.MIN and LocalDate.MAX special, caused more problems than it solved. Some of the resulting quirks are documented, some aren't.

I'll try to show several things at once using one example.

LocalDateRange range = LocalDateRange.ofClosed(
    LocalDate.MAX.minusDays(1), LocalDate.MAX.minusDays(1)
);
range.isEmpty();                            // -> false (of course)
range.lengthInDays();                       // -> 1     (so far, so good)
range.contains(LocalDate.MAX.minusDays(1)); // -> true  (obviously)
range.contains(LocalDate.MAX);              // -> true  (what???)
range.isUnboundedEnd();                     // -> true  (it's getting worse...)

Seems like non-empty range of length 1 contains 2 days, all of that despite being unbounded at the end. On the surface, no LocalDate.MAX involved. Weird.

As you can see, (3) isEmpty, contains, lengthInDays and isUnboundedStart / isUnboundedEnd are inconsistent with each other.

Needless to say, problem with non-expressibility hasn't disappeared. There is still no way to represent [LocalDate.MAX.minusDays(1), LocalDate.MAX.minusDays(1)]. Internally, it is indistinguishable from [LocalDate.MAX.minusDays(1), +∞). Everything close to LocalDate.MAX becomes suspicious. This is documented, but consequences are not so obvious and can be surprising.

There are similar problems with LocalDate.MIN too. For instance, [LocalDate.MIN, LocalDate.MIN) is empty and unbounded at the same time.

I know it's rather unlikely to happen, but the least I can do is to leave my two cents here. Sticking to always bounded [a, b) would be perfect. It is possible to migrate in almost entirely backward compatible way.

1. No more infinities. From now on, isUnboundedStart and isUnboundedEnd are returning false unconditionally.
2. [*, LocalDate.MAX] silently becomes [*, LocalDate.MAX), just as it is now. The only change is that resulting range doesn't contain LocalDate.MAX.

I agree that everything what I've just described.. those are "just" edge-cases. They should't cause much trouble in real life. And maybe they won't. However, I would argue that if there have to be some quirks in the implementation - and we're stuck with (2) I believe - they should be as "local" and "constrained" as possible (for the lack of better words). It's easier to reason about code when there's only one method referring to edge case (ofClosed), than where there are many (of, getEnd, getEndInclusive, contains).

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

Resolves #137

Relevant ThreeTenBP commit: https://github.com/ThreeTen/threetenbp/commit/d9ad1de4c63817275c27a464781a08cb3d3d920f

Checklist:

• [x] Add OffsetDate.java
• [x] Fix OffsetDate compilation
  • Implemented OffsetDate.isSupported(TemporalUnit)
  • Removed custom serialization
• [x] Add TestOffsetDate.java
• [x] Fix TestOffsetDate compilation
• [x] Fix TestOffsetDate tests
  • Removed custom serialization testing
• [x] Align API with those of OffsetDateTime and OffsetTime
  • [x] Rename toString(DateTimeFormatter) to format(DateTimeFormatter)
  • [x] Rename getDate() to toLocalDate()
  • [x] Implement from(int, int, int, ZoneOffset)
  • [x] Implement toEpochSecond(LocalTime)
  • [x] Rename withOffset(ZoneOffset) to withOffsetSameLocal(ZoneOffset)
• [x] Improve test coverage
• [x] Miscellaneous
  • [x] Add Joda-Convert annotations
  • [x] assertEquals(true, ...) -> assertTrue(...) etc.
  • [x] Update copyright header
  • [x] Add contributor

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?

Hello 3-10 stakeholders

This changes have been incorporated from the code review:

• InternationalFixedChronology is now final
• method names now followed directly by open parenthesis
• corrected comments referring to Julian or Pax chronologies
• member item comments not preceded by a blank line anymore
• deprecated InternationalFixedChronology constructor and commented accordingly
• grouping of methods aligned, followed the examples of PaxDate and PaxChronology
• InternationalFixedChronology#eraOf now has return type InternationalFixedChronology
• Corrected exception messages to better reflect the error
• the name 'International Fixed' calendar was chosen by Cotsworth, and yes, it was boldly done for global spreading. Perhaps a better name would be KodakFixedChronology / KodakFixedDate, since it was used for 71 years at Eastman Kodak internally. Another choice is CutsworthFixedChronology / CutsworthFixedDate.
• Corrected comments on the alignment of Fixed calendar with Gregorian calendar
• Corrected (non-leap) year constant DAYS_IN_YEAR to hold 365 days
• introduced a factory method which validates a given date first, only invokes the constructor if date is accepted
• Corrected year-range check in InternationalFixedDate
• Corrected leap-year check in factory method to call InternationalFixedChronology#isLeapYear(long)
• Corrected CheckStyle warnings and errors for fixed chronology, era and date
• Generated new serial version UID for fixed chronology and date
• Corrected tests affected by code changes above
• Added missing range checks
• Re-worked the internal representation of InternationalFixedDate, to distinguish between calendar days and month-less days.
• Added test cases for leap-day and year-day.
• Added test cases for dateYearDay
• Implemented day-of-week and test cases.

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.

Hi, I may just be missing something, but I'm trying to use the AccountingChronology to create a calendar that matches the (US) National Retail Federation calendar, a 454 calendar, ending the year on the last Saturday in January: https://nrf.com/resources/4-5-4-calendar.

I setup my chronology as follows

        AccountingChronology nrfChronology = new AccountingChronologyBuilder()
                .endsOn(DayOfWeek.SATURDAY) 
               
 .withDivision(AccountingYearDivision.QUARTERS_OF_PATTERN_4_5_4_WEEKS) 
                .inLastWeekOf(Month.JANUARY) 
                .leapWeekInMonth(1)
                .toChronology();

Everything seems ok, except the next Federation leap year is 2023, but my chronology has leap years in 2021 and 2026. Is there something I can do to shift the leap year?

…tains check.

I see my developers often having problems with the closed/open properties of Intervals. In this case there is no built in function to point them to leading the developers to "duplicate" the inclusive/exclusive properties into call sites of getStart()/getEnd().

The concrete use case they ran into was filtering a list of intervals that preceded or overlapped an instant leading them to duplicating the inclusiveness of start like: list.filter { it.start <= now }.

I dont think the name is 100% spot on but.. yeah :)

I have a question, when using this library to calculate HijrahDate, sometimes it is a day late. E.g Convert today 2020-1-7 to HijrahDate: 1441-5-12 But the result calculated using this library is: 1441-5-11 What is the reason at this time?

Bumps checkstyle from 8.41 to 8.45.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

This is an attempt to make Interval parsing more readable and (hopefully) less error prone. I believe that proposed way of splitting code into methods makes much more sense than before. At least one bug was fixed. At the same time, parsing became a little more flexible.

The bug was caused by the following:

long move = end.isBefore(Instant.EPOCH) ? 1000 * 86400 : -1000 * 86400;
Instant start = end.plusSeconds(move).atOffset(ZoneOffset.UTC).minus(amount).toInstant().minusSeconds(move);

long move = start.isBefore(Instant.EPOCH) ? 1000 * 86400 : -1000 * 86400;
Instant end = start.plusSeconds(move).atOffset(ZoneOffset.UTC).plus(amount).toInstant().minusSeconds(move);

It looks like author's intention was to move instant 1000 days towards Instant.EPOCH. First, it is not exactly 1000 days - it's approximately 1000 days. What's important is that it can (but doesn't have to) move instant into month with different number of days. I decided to use leap year cycle length (which is fixed) to avoid this kind of problems.

Without this fix, not a single test covered by org.threeten.extra.TestInterval.data_parse_outside_bounds(String, String, String) is going to pass. For instance -1000000000-01-31T00:00:00Z/P1M should be parsed to interval ending at -02-29, not -03-02 and for -1000000000-01-31T00:00:00Z/P2M interval's end should be -03-31 instead of -04-01 .

There are still some cases that this rewrite doesn't fix. All of them involve duration. Please, see org.threeten.extra.TestInterval.data_parse_crossing_bounds(String, String, String) (intervals starting within date-time bounds, with duration making them end outside of it) and org.threeten.extra.TestInterval.data_parse_crossing_bounds_twice(String, String, String) (intervals starting before OffsetDateTime.MIN and ending after OffsetDateTime.MAX because of duration). Maybe someone will be interested in making these tests pass - for now, they are disabled.

For <start>/<end> expressions, if any elements are missing from the end value, they are assumed to be the same as for the start value including the time zone (https://en.wikipedia.org/wiki/ISO_8601#Time_intervals)

Edit: I must have misread something. If desired, I can easily revert old behavior.

Probably related: #80.

In one of our projects use the extra maven enforcer rule enforceBytecodeVersion to ensure that artifacts we believe to be JDK 8 compliant actually are.

This fails when running against threeten-extra 1.7.1:

[INFO] --- maven-enforcer-plugin:3.1.0:enforce (enforce) @ bom-integration-test ---
[INFO] Adding ignore: module-info
[INFO] Restricted to JDK 8 yet org.threeten:threeten-extra:jar:1.7.1:compile contains org/threeten/extra/chrono/package-info.class targeted to JDK 9
[ERROR] Rule 3: org.apache.maven.plugins.enforcer.EnforceBytecodeVersion failed with message:
Found Banned Dependency: org.threeten:threeten-extra:jar:1.7.1

We can get around this with exclusions I noticed that the package-info.class files are not in the 1.7.0 jar file, but they are included in 1.7.1 with bytecode version 53. Is this intentional?

Support concept of Year Half. This is useful for some industries, such as finance, to represent the beginning or trailing ends of a year.

AFAIK there is no standard representation, but typically <year>-H<1|2> (e.g. 2022-H2) is used and similar to Year Quarter.

This implements the MISP time system as described in the MISB Motion Imagery Handbook (downloadable from https://nsgreg.nga.mil/doc/view?i=5306 - sorry, direct links frequently broken). The implementation follows the TaiInstant implementation, and makes use of the TAI conversion routines where practical.

Resolves #194

The PR includes unit tests for all added code.

There is a change to the UtcRules implementation that adds an abstract method. That won't be source compatible for anyone implementing their own rules (i.e. its arguably an API break). It is not strictly necessary to do so, and although I think the implementation makes more sense in the SystemUtcRules, I could see a case for not doing it that way. I'll update the PR to avoid that if required.

Hi there,

this PR contains four TemporalAdjuster to round time to the nearest part of an hour. Rounding to the nearest part of an hour is often done in payroll systems, scheduling and appointment making.

• Add public static TemporalAdjuster nearestHalf to Temporals
• Add public static TemporalAdjuster nearestQuarter to Temporals
• Add public static TemporalAdjuster nearestTenth to Temporals
• Add public static TemporalAdjuster nearestTwelfth to Temporals

The code is repetitive and contains hardcoded numbers. Granted not the most clever approach, but it is straightforward and easy to read and maintain.

I know this project emphasizes well written JavaDoc. I am not a native speaker. I tried.