[gabrielcaires]

Fixes #313

Problem

roundToSingleUnit turned N days + H hours into days by rounding the hours (days += Math.round(hours / 24)). "Yesterday" is a calendar concept, so a date 36–37 hours ago that is still on the previous calendar day showed as "2 days ago", while 38h ago (also yesterday) showed "yesterday" again.

Example from the issue (local time): now is Apr 30 13:53, date is Apr 29 00:53 → -P1DT13H → was "2 days ago", now "yesterday".

Change

• When a duration has days but no weeks/months/years, days is the number of calendar days between relativeTo and the target date (applyDuration(relativeTo, duration)), compared at local midnight and rounded so DST days of 23h/25h still count as one day. Other cases keep the existing rounding.
• The element passes the now it used for elapsedTime as relativeTo, plus the exact date, to the relative and micro formatters. Calendar days are counted from the real date rather than one rebuilt from the precision-truncated duration (dropped milliseconds, precision="hour"/"day"), and both rounding passes in the micro path agree.
• On a 25 hour DST day, a full day of elapsed time can stay on one calendar date; that case stays in hours ("24 hours ago") instead of rounding away.

The duration format without micro doesn't call roundToSingleUnit and is unaffected.

Tests

• New roundToSingleUnit cases for the issue scenario (past and future), for the 2 days + under 1 hour window right after/before midnight, and a case that stays at 2 days.
• P1DT20H / P1DT18H used the default relativeTo (midnight), where +1d20h is calendar "tomorrow". They now use noon, which gives P2D in both directions.
• Cases for the exact date option (truncated milliseconds, precision="day") and the DST same-day case.
• npm test passes (647 tests).

The rewrite proposed in #301 also counts calendar days and would cover this issue.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

Unresolved DST handling and fractional-second truncation defects produce incorrect relative times, including “now” for a 24-hour-old timestamp and off-by-one future day counts.

3 open issues

• DST fall-back makes a 24-hour-old timestamp display as now · New
• Second precision can undercount calendar days near midnight · New
• Re-rounding the micro duration can show two days instead of one · New

What changed in this PR

This PR addresses #313 by using local calendar-day differences for day-level relative-time rounding, so “yesterday” and “tomorrow” better match calendar dates.

Changes:

• Replaces hour-based day rounding with local calendar-day counting for durations without weeks, months, or years.
• Passes the same reference time through elapsed-time calculation and relative/micro formatting.
• Adds regression cases for past and future dates near midnight.

File	Description
test/​duration.ts	Adds calendar-day regression cases and explicit reference times.
src/​relative-time-element.ts	Shares the reference time with relative and micro formatters.
src/​duration.ts	Adds local calendar-day counting to single-unit rounding.

_{Review effort: Balanced (auto)}

[Copilot]

🟡 Changes recommended

Unresolved calendar-day rounding issues produce incorrect durations, ignore the configured time zone, and leave labels stale across midnight, while existing tests have become clock-dependent.

4 open issues

• Freeze the clock in calendar-rounding tests · New
• Schedule refreshes at the next relevant midnight · New
• Avoid re-rounding the duration when selecting its display unit · New
• Use the element's resolved time zone for calendar-day rounding · New

3 resolved since last review

• Re-rounding the micro duration can show two days instead of one
• Second precision can undercount calendar days near midnight
• DST fall-back makes a 24-hour-old timestamp display as now

_{Review effort: Max}

[Copilot]

🟡 Changes recommended

Unresolved date-handling bugs delay refreshes when DST skips across midnight and treat timestamp 0 as missing, producing incorrect relative-day output.

1 open issue

• Schedule refresh at the actual date boundary across DST jumps · New

1 previously missed issue

In code that hasn't changed since last review

Treat timestamp zero as a valid date option

src/​duration.ts:245

The new date option accepts numeric timestamps, but this truthiness check treats the Unix epoch (0) as missing. With relativeTo: new Date('1969-12-30T10:00:00.500Z'), date: 0, timeZone: 'UTC', and duration P1DT13H59M59S, the fallback reconstructs December 31 just before midnight and returns P1D instead of P2D. Check against undefined so numeric zero receives the same exact-date handling as new Date(0).

4 resolved since last review

• Use the element's resolved time zone for calendar-day rounding
• Avoid re-rounding the duration when selecting its display unit
• Schedule refreshes at the next relevant midnight
• Freeze the clock in calendar-rounding tests

_{Review effort: Max}

[Copilot]

🟡 Changes recommended

The helper misses backward calendar-date changes, leaving labels stale for 30 minutes, and performs unnecessary time-zone formatting calls on every observer tick.

2 open issues

• Find the next calendar-date change in either direction · New
• Stop the midnight search once the next date is reached · New

1 resolved since last review

• Schedule refresh at the actual date boundary across DST jumps

_{Review effort: Max}

[Copilot]

🔵 Needs a closer look

Human review is needed to assess a spring-forward boundary case where elapsed-hour rounding understates calendar-day differences and produces an incorrect relative-day label.

No open issues 🎉

2 resolved since last review

• Stop the midnight search once the next date is reached
• Find the next calendar-date change in either direction

_{Review effort: Max}

[Copilot]

🟡 Changes recommended

The fallback in src/duration.ts drops the 21+ hour-to-day carry when days is zero, causing a regression in month/year rounding.

1 open issue

• Preserve hour-to-day carry for month and year rounding · New

_{Review effort: Max}

[Copilot]

🔵 Needs a closer look

Human assessment is needed because date reconstruction around the year 0099–0100 boundary can cause duration rounding to report hundreds of thousands of calendar days instead of one.

No open issues 🎉

1 resolved since last review

• Preserve hour-to-day carry for month and year rounding

_{Review effort: Max}

[Copilot]

🔵 Needs a closer look

Human assessment is needed because explicit-zone era handling can miscount a one-day interval across year zero as 364 days and round it to a year.

No open issues 🎉

_{Review effort: Max}

[liuliu-dev]

@gabrielcaires thanks for addressing the copilot findings ❤️ ! The changes LGTM!