Summary

In pm meet/pm event/pm remind, --duration 5m is parsed as 5 months, not 5 minutes. The minute form is 5min. The help text only documents 1h/2d examples and never warns that m = month, so a user scheduling a "5-minute standup" silently creates a 5-month meeting.

Impact

High probability of silent wrong data for the most common scheduling case. Meetings, reminders, and events are created with wildly wrong durations and there is no warning (warnings: [] in the JSON). Users discover the error only when the event shows up months later (or never, in an agenda window). The convention in nearly every other scheduling tool (cron, ISO 8601 durations, Google Calendar, cron-like CLIs) is m=minute and either mo/mon=month or no single-letter month. This is a data-correctness footgun disguised as a friendly shortcut.

Environment

• pm version: 2026.7.4
• Node version: v22.20.0
• OS: Linux pop-os 7.0.9 x86_64
• Install method: npm install -g @unbrained/pm-cli
• Project state: fresh tracker

Area

CLI / scheduling (duration unit parsing)

Reproduction

From a clean folder:

export PM_PATH="$(mktemp -d)/.pm"
pm init --defaults --agent-guidance skip
# 1. What most users mean by "5m":
pm meet "Standup" --start +1h --duration 5m --json
#   -> events[0].end_at is 5 MONTHS after start (2026-12-05 vs 2026-07-05)
#   -> warnings: []  (no warning!)
# 2. The actual minute form:
pm meet "Standup2" --start +1h --duration 5min --json
#   -> events[0].end_at is 5 MINUTES after start
# 3. Help does not document the m/min distinction:
pm help meet | grep -A2 duration
#   -> "--duration <span>  Duration from start (relative like 1h/2d)"

Expected

• 5m should be minutes (the dominant convention), OR
• if m/month is intentional, the help must document the full unit vocabulary (min=minute, m/mo=month, h=hour, d=day, w=week) prominently, AND
• a duration ≥ some sane threshold (e.g. > 30 days for a meeting) should emit a warning.

Actual

5m = 5 months silently; 5min = 5 minutes; help shows only 1h/2d; no warning on a 153-day meeting.

Evidence

• repro directory: repros/duration-unit-parsing-ux/ (repro.sh, actual.txt)
• key excerpt: --duration 5m → start 2026-07-05T17:06:53Z, end 2026-12-05T17:06:53Z (DELTA_DAYS=153)
• --duration 5min → start 17:06:53, end 17:11:53 (DELTA_MIN=5)

Duplicate search performed

• gh issue list -R unbraind/pm-cli --state all --search "duration minute month m min" --limit 20
• gh issue list -R unbraind/pm-cli --state all --search "duration 5m parsing" --limit 20

Workaround

Always use min for minutes. Discoverable only by trial-and-error.

Proposed improvement

1. Make m = minute (align with cron/ISO/crowd convention); use mo for month if needed.
2. Document the full unit set in --duration help with a unit table.
3. Emit a warning when a Meeting/Event duration exceeds a threshold (e.g. 1 day), since a >1-day meeting is almost always a unit mistake.

Dogfood context

Found in Phase 10 of the ContextOps dogfood while testing scheduling inputs. I created a meeting with --duration 5m intending 5 minutes and noticed the agenda placed it 5 months out.