Skip to content

Show clock time on due dates that aren't end-of-day - #660

Open
tanvdo wants to merge 4 commits into
mainfrom
tan/auto-closing-tasks
Open

Show clock time on due dates that aren't end-of-day#660
tanvdo wants to merge 4 commits into
mainfrom
tan/auto-closing-tasks

Conversation

@tanvdo

@tanvdo tanvdo commented Aug 13, 2026

Copy link
Copy Markdown

Overview

Issue: https://github.com/CareEvolution/Consumers/issues/13395

Related PRs

SingleSurveyTask's due-today/due-tomorrow labels currently show no clock time, so "Due
Tomorrow" is ambiguous — it could mean anywhere from a few minutes to nearly 48 hours away.

getDueDate() now infers whether a due date was snapped to local end-of-day (a new
isEndOfLocalDay heuristic — within ~1 minute of local midnight) or is genuinely time-specific.
End-of-day dates keep the plain due-today/due-tomorrow/overdue labels unchanged. Anything
else now renders with a clock time, e.g. "Due Today at 1:00 AM" / "Due Tomorrow at 1:00 AM", using
a new getStrictTimeFromNowString helper (formatDistanceToNowStrict) for the "due in N" case to
avoid vague "about"/"almost" qualifiers.

Also fixes a real bug found along the way: the time-specific branch compared against
startOfToday() instead of the current moment, so a task due earlier today (e.g. 9am) kept
reading "Due Today at 9:00 AM" all afternoon instead of "Overdue".

New due-today-with-time/due-tomorrow-with-time locale keys added to all 16 supported locale
files (non-English translations are best-effort and could use a native-speaker pass before wide
release). Five new Storybook stories cover both with-time cases plus the day-granular-overdue,
precise-overdue, and precise-due-in-days branches.

Security

  • I have ensured no secure credentials or sensitive information remain in code, metadata, comments, etc.
    • Please verify that you double checked that .storybook/preview.js does not contain your participant access key details.
    • There are no temporary testing changes committed such as API base URLs, access tokens, print/log statements, etc.
  • These changes do not introduce any security risks, or any such risks have been properly mitigated.

No security risk: this is a pure display-formatting change to an already-public due-date string,
with no new data sources, network calls, or credentials involved.

Testing

  • This change can be adequately tested using the MDH Storybook.

In Storybook, open SingleSurveyTask and check these stories:

  • DueTodayWithTime — due date is later today; label should read "Due Today at <time>".
  • DueTomorrowWithTime — due date is tomorrow; label should read "Due Tomorrow at <time>".
  • OverdueDayGranular — due date was yesterday, snapped to 23:59; label should read "Overdue"
    with no clock time.
  • OverdueEarlierToday — due date was a few hours ago today (not midnight-snapped); label should
    read "Overdue" (previously this incorrectly showed "Due Today at <time>" — verify the fix).
  • DueInDays — due date is 3+ days out; label should read "Due in <time>" using a tight duration
    like "3 days", not "about 3 days".

Also spot-check a non-English locale (e.g. switch Storybook's locale to de or vi) to confirm
the new due-today-with-time/due-tomorrow-with-time strings render instead of falling back to
a missing-key placeholder.

Documentation

  • I have added relevant Storybook updates to this PR.
  • If this feature requires a developer doc update, I have tagged @CareEvolution/api-docs.
  • This change does not impact documentation or Storybook.

Reviewers

Assign to the appropriate reviewer(s). Non-English translations for the two new locale keys were
generated, not written by native speakers — worth a callout to a reviewer who can sanity-check
them or route to translators.

tanvdo and others added 4 commits August 13, 2026 05:18
getStrictTimeFromNowString wraps date-fns's formatDistanceToNowStrict
with the same getDateLocale() plumbing as the existing
getTimeFromNowString, producing a tighter "3 hours" instead of "about 3
hours" for future dates.

isEndOfLocalDay is a heuristic: true when a timestamp is within about a
minute of local midnight (23:59:xx or 00:00:xx), used to infer whether a
due date was snapped to end-of-day rather than genuinely time-specific.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QkUEA9bCk35Y5PdKXsJQsc
New locale keys for SingleSurveyTask's upcoming clock-time display, in
all 16 supported locales.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QkUEA9bCk35Y5PdKXsJQsc
Due dates that fall today or tomorrow are ambiguous on their own (a
task "due tomorrow" could mean anywhere from a few minutes to nearly 48
hours away once snapped to end-of-day). Append the local clock time to
the due-today/due-tomorrow labels, e.g. "Due Today at 1:00 AM", so the
remaining time is unambiguous.

The SurveyTask SDK type carries no precision flag, so day-granular due
dates (snapped to local end-of-day) are inferred heuristically via
isEndOfLocalDay and rendered without a clock time - the time would just
be an artifact of the snap. Everything else (a legacy pre-snap task, a
genuinely time-specific due date, or a traveling participant whose
local midnight has shifted) is treated as effectively precise and
rendered with one, using getStrictTimeFromNowString for the "due in N"
case to avoid vague qualifiers like "about".

Also fixes a bug in the precise-time branch: overdue was compared
against startOfToday() instead of the current moment, so a task due
earlier today read as "Due Today at 9:00 AM" instead of "Overdue".

Adds Storybook stories covering both due-today/due-tomorrow-with-time
cases, the day-granular overdue case, the effectively-precise overdue
case, and the effectively-precise "due in N days" case.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QkUEA9bCk35Y5PdKXsJQsc
@aws-amplify-us-east-1

Copy link
Copy Markdown

This pull request is automatically being deployed by Amplify Hosting (learn more).

Access this pull request here: https://pr-660.d1xp2kmk6zrv44.amplifyapp.com

@tanvdo
tanvdo requested review from ajmenca and greinard August 13, 2026 20:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant