skip to content

Using TemporalAdjusters and truncatedTo, how would you compute a deterministic billing window: the start-of-day on the first of next month, and the inclusive last instant of the current month?

level: seniorimportance: should knowfreq 30%

answer

  1. Model month as half-open [first-of-month 00:00, first-of-next-month 00:00)
  2. Exclusive next-day bound avoids the 23:59:59.999 lost-fraction bug
  3. firstDayOfNextMonth handles leap years / month length for you
  4. Inclusive end = next-month-start.minusNanos(1)
  5. Truncate to storage precision (MICROS/MILLIS) for deterministic compares

basics

~20 s

Start of next month: date.with(firstDayOfNextMonth()).atStartOfDay(). The clean way to bound the current month is a half-open range [firstDayOfMonth at 00:00, firstDayOfNextMonth at 00:00), using less-than for the upper bound instead of trying to find the exact last instant.

solid answer

~40 s

For month boundaries, prefer a half-open interval over hunting for the exact last nanosecond. The start is date.with(TemporalAdjusters.firstDayOfMonth()).atStartOfDay() and the exclusive end is date.with(TemporalAdjusters.firstDayOfNextMonth()).atStartOfDay(); you then query with start <= t < end. This avoids the classic bug of picking 23:59:59.999 and missing events in the final fraction of a second, and it sidesteps precision mismatches between nanosecond in-memory values and millisecond/microsecond storage. If a half-open range is genuinely impossible and you must produce an inclusive last instant, take firstDayOfNextMonth().atStartOfDay() and subtract one nanosecond (or truncate to your storage precision first to keep comparisons deterministic). truncatedTo(ChronoUnit.DAYS) gives start-of-day on a LocalDateTime; firstDayOfMonth/lastDayOfMonth handle variable month lengths and leap years automatically, so you never compute 28/29/30/31 yourself.

code

java · 9 lines
java
LocalDate any = LocalDate.of(2026, 6, 20);

// Preferred: half-open range [start, end)
LocalDateTime start = any.with(TemporalAdjusters.firstDayOfMonth()).atStartOfDay();      // 2026-06-01T00:00
LocalDateTime end   = any.with(TemporalAdjusters.firstDayOfNextMonth()).atStartOfDay();  // 2026-07-01T00:00
// query rows where start <= t && t < end

// If an inclusive last instant is mandated (matched to micro-precision storage):
LocalDateTime lastInstant = end.minusNanos(1).truncatedTo(ChronoUnit.MICROS); // 2026-06-30T23:59:59.999999

go deeper

for a junior

Can produce start-of-next-month with firstDayOfNextMonth().atStartOfDay() but may default to an inclusive end bound.

for a middle

Uses adjusters for month edges and avoids hardcoding day counts; aware of start-of-day.

for a senior

Defaults to half-open ranges, explains why inclusive end and precision mismatches are buggy, and truncates to storage precision.

for a principal

Standardizes time-range modeling across services (half-open, UTC/zone policy, storage precision), and reviews reporting/billing for boundary correctness at scale.

## The task Billing, reporting, and analytics constantly need "all events in month M." Done naively this is a minefield of off-by-one and precision bugs. java.time's adjusters plus `truncatedTo` make it clean — *if* you model the range correctly. ## Why half-open ranges are the right model A time **range** is best expressed as **half-open**: `[start, end)`, meaning start is included and end is excluded (`start <= t < end`). For a month: ``` LocalDate any = LocalDate.of(2026, 6, 20); LocalDateTime start = any.with(TemporalAdjusters.firstDayOfMonth()).atStartOfDay(); // 2026-06-01T00:00 LocalDateTime end = any.with(TemporalAdjusters.firstDayOfNextMonth()).atStartOfDay(); // 2026-07-01T00:00 // query: start <= t AND t < end ``` `atStartOfDay()` turns a `LocalDate` into a `LocalDateTime` at 00:00. `firstDayOfMonth()`/`firstDayOfNextMonth()` are adjusters that handle every month length and leap years for you — you never write `28/29/30/31` logic. Why half-open wins: - **No lost final fraction.** The infamous `23:59:59.999` upper bound (inclusive) silently drops any event between `.999` and the true end of the day. With an exclusive `00:00` next-day bound, nothing is missed. - **Precision-agnostic.** It doesn't matter whether your timestamps are millis, micros, or nanos; `t < 2026-07-01T00:00` is correct at every precision. An inclusive 'last instant' must match the storage precision exactly or it leaks/loses rows. - **Adjacent ranges tile perfectly.** This month's `end` equals next month's `start`, so consecutive ranges neither overlap nor gap. ## If you truly need an inclusive last instant Sometimes an external contract demands a closed upper bound. Then derive it from the start of next month and step back by your smallest unit: ``` LocalDateTime lastInstant = any.with(TemporalAdjusters.firstDayOfNextMonth()) .atStartOfDay() .minusNanos(1); // 2026-06-30T23:59:59.999999999 ``` But beware: if your database stores only **microseconds** or **milliseconds**, that nanosecond value won't round-trip equal. Truncate to the storage precision so comparisons are deterministic: ``` LocalDateTime lastMicros = any.with(TemporalAdjusters.firstDayOfNextMonth()) .atStartOfDay() .minusNanos(1) .truncatedTo(ChronoUnit.MICROS); ``` This is the **nanosecond-vs-millisecond consideration** in practice: in-memory java.time carries nanos, most stores carry less, so equality/range comparisons across the boundary must be normalized. ## Role of each tool - **TemporalAdjusters** position you on the right *date* (first of this/next month) regardless of month length or leap years. - **truncatedTo** controls *precision* — `truncatedTo(ChronoUnit.DAYS)` is an alternative to `atStartOfDay()` on an existing `LocalDateTime`, and truncating to MICROS/MILLIS aligns with storage. - **Half-open modeling** is the discipline that makes the whole thing correct. ## Leap-year / variable-length safety Because you never hardcode the last day number, February (28 vs 29), 30-day, and 31-day months all just work: `firstDayOfNextMonth()` always lands on day 1 of the following month, and stepping back one unit gives the correct true end. This is exactly the kind of off-by-one that hand-rolled `Calendar` math used to get wrong.

  • Why is the inclusive '23:59:59.999' upper bound a bug?
    It excludes any event between .999 and the real end of the day (down to nanoseconds). A half-open exclusive bound at next-day 00:00 includes everything in the day with no lost fraction.
  • How do adjacent half-open month ranges interact?
    This month's exclusive end equals next month's inclusive start (both first-of-next-month 00:00), so consecutive ranges tile perfectly with no overlap and no gap.

saying these in an interview costs you the question

  • Using inclusive 23:59:59.999 and missing the final sub-second of events
  • Hardcoding 28/29/30/31 instead of using firstDayOfNextMonth
  • Comparing a nano-precision last instant against millis-precision DB rows
  • Building overlapping or gapped adjacent ranges (use tiling half-open bounds)

context

resolving links…