Web: show the time and time zone of payer-transfer response deadlines

Open
  • Is something wrong?
#784 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@Hrushikesh-ramilla is already working on this.

Since Nov 1, 2026.

  • #787 by @Hrushikesh-ramilla — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
25/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Stale
Tech stack
react, typescript
Domain
frontend

Research direction

The date formatter is in web/src/PayerTransferInbox.tsx around line 23, and the Respond by label is rendered near line 230. Start by reading how the earlier of consentExpiresAtEpoch and effectiveFrom is chosen, then add a deterministic time and zone display. Run npm --prefix web test -- src/tests/PayerTransferPagination.test.tsx and the web typecheck; done means the consent-earlier and renewal-earlier cases render distinguishable labels. Linked PR #787 is already open against this, so check it before starting.

Written by the indexing model from the issue text.

Description

enhancement good first issue help wanted

The problem

The payer-transfer inbox shows Respond by [date], but invitations expire at a specific timestamp. The date-only label cannot distinguish a morning deadline from an evening deadline, leaving users unsure how long they have to respond.

Show the response deadline's time of day and time zone as well as its date. This is a presentation enhancement; the existing expiration rules should remain unchanged.

Evidence

Verified on clean main 3a77d68cf55a51da33d624203b41c1878dce8a7e with a temporary component test:

  1. Render two synthetic, actionable incoming transfers with consent deadlines 2035-01-02T09:00:00Z and 2035-01-02T17:00:00Z, and renewal boundaries later than both deadlines.
  2. Read their Respond by labels.
  3. Both labels contain identical text despite the eight-hour difference. Neither includes the time.

The component currently formats the earlier of consentExpiresAtEpoch and effectiveFrom with toLocaleDateString("en-GB").

Ran the probe with the existing pagination test: 2 passed using npm --prefix web test -- src/__tests__/PayerTransferPagination.test.tsx. The temporary probe was removed afterwards. Environment: macOS arm64, Node v24.15.0, Vitest 5.0.5 / happy-dom 21.0.4. API responses were mocked; no live invitation or billing operation was exercised.

Acceptance criteria

  • The Respond by label includes a human-readable date, time of day and explicit time-zone indication. Use a consistent, documented display choice (for example the browser's local zone, or explicitly labelled UTC).
  • Continue displaying the earlier of the consent expiry and renewal boundary. Do not change the underlying epoch values, expiry timer or action-availability rules.
  • Two different deadline times on the same day produce distinguishable labels.
  • Add deterministic component coverage for consent expiry being earlier and for renewal being earlier. Avoid relying on the developer machine's time zone when asserting expected output.
  • Preserve existing expired-invitation behaviour and tests. Keep this change scoped to the response deadline, rather than changing every date or billing label in the application.
  • Run the relevant payer-transfer tests and web typecheck.

Starting points

Checked open and closed issues and open PRs. #636 covers automatic expiry updates and #696 / PR #698 covers the wording after expiration. This task improves the deadline shown before expiration; it does not alter either behaviour.

Where this lives

  • Web client

Suitable for a first contribution: a small date-formatting change with existing component-test fixtures. Follow CONTRIBUTING.md, use British English, and sign off commits with git commit -s.

Dominant language
Rust
Stars
31
Forks
42
Avg merge
2d 18h
Merged PRs (30d)
142

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from getsotto/sotto

All issues in getsotto/sotto

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.