[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}