Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Fix: progress renders assessed_at as UTC day, diverging from local last_reviewed

Open Beginner friendly
  • Is something wrong?
#541 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
88/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
node.js, typescript
Domain
cli

Research direction

Read src/cli/progress.ts around lines 155–168 and check how it formats assessed_at and last_reviewed_at; compare the date helper in src/engine/sm2.ts and the existing invalid-string fallback test. Update the display to use the local calendar date, then confirm both values show the same day for timestamps near UTC midnight.

Written by the indexing model from the issue text.

Description

bug cli priority: medium

palee progress shows Last Assessed a day off from Last Reviewed

This is the kind of thing that makes you second-guess your own memory. Ran
palee review and palee assess on the same topic seconds apart, then
palee progress --topic <id>. The output showed:

Last Assessed: 2026-10-24
Last Reviewed: 2026-10-25

But I ran the review before the assess. The dates are on different clocks.

Reproduction
# On a machine in IST (UTC+5:30), at 23:43 local:
palee review T-somtopic 4
sleep 15
palee assess T-somtopic --conceptual 0.7
palee progress --topic T-somtopic
# Shows "Last Assessed: 2026-10-24" / "Last Reviewed: 2026-10-25"
Root cause

Two different write paths, two different timebases:

  • src/application/record-review.ts:108 writes last_reviewed_at as a
    local date-only string via formatLocalDateOnly(reviewedAt).
  • src/application/record-assessment.ts:100 writes assessed_at as a
    full UTC ISO instant via assessedAt.toISOString().

Then src/cli/progress.ts:155-168 renders both through the same expression:

new Date(value).toISOString().split('T')[0]

For the local date-only string, this round-trips fine. But for the UTC
ISO instant, .toISOString().split('T')[0] gives you the UTC calendar
day — which can be yesterday or tomorrow relative to the learner's local
calendar.

So if you're in IST and assess at 23:43 local, the UTC ISO is
2026-10-24T23:43:34Z → progress shows 2026-10-24. Meanwhile review wrote
2026-10-25 (local) → shows 2026-10-25. Hence the "review is a day after
the assess that happened first" illusion.

src/cli/review.ts:113 already renders its due date via formatLocalDateOnly
(local), so the two adjacent commands disagree on timebase.

ADR / convention

agent.md:41 (ADR-0005): dates use local calendar day.
record-review.ts:44-47 explicitly documents the hazard: "new Date('YYYY-MM-DD')
reads as UTC midnight and would make same-day local reviews look early west of
UTC."

Acceptance criteria
  • progress.ts routes date-only display through formatLocalDateOnly
    (already imported by sibling commands, exported from src/engine/sm2.ts:189-194).
  • assessed_at and last_reviewed_at render the same calendar day as the
    learner's local timezone.
  • No existing test breaks (current tests pin only the invalid-string fallback).

I did not use AI to generate this issue report.

Dominant language
TypeScript
Stars
1
Forks
0
Avg merge
15h 54m
Merged PRs (30d)
163

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

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 Kuldeep2822k/cli

All issues in Kuldeep2822k/cli

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.