Time Tracking

Why Manual Time Tracking

Daylight uses manual time entry instead of start/stop timers. You log how long you worked on a task after the fact, rather than running a clock while you work. This is a deliberate choice — timers create more problems than they solve for most task workflows.

The Case Against Timers

Timers assume uninterrupted, single-task work sessions. Real work doesn’t look like that:

• Interruptions: A Slack message, a quick question from a colleague, a bathroom break. The timer keeps running through all of it, inflating the logged time.
• Context switching: You start a timer on Task A, get pulled into Task B, forget to switch the timer. Now Task A has 90 minutes logged and Task B has zero.
• Forgotten starts/stops: The most common timer failure. You forget to start it, or forget to stop it, and the entry is useless.

Manual Entry Benefits

Logging time after the work is done produces more accurate records with less friction:

• Retrospective accuracy: You know you spent about 45 minutes on the report. That’s more reliable than a timer that ran through your lunch break.
• Batch entry: Forgot to log yesterday? Add entries for any past date. No lost data because you didn’t start a timer.
• No timer anxiety: Timers create a low-grade pressure to justify every minute. Manual entry removes that overhead entirely.

How It Works

Adding a Time Entry

Time entries are embedded directly in each task’s YAML frontmatter. Each entry records the date, duration in minutes, and an optional note:

---
title: Write documentation
time_entries:
  - date: 2026-01-27
    duration: 90  # minutes
    notes: "API reference section"
  - date: 2026-01-27
    duration: 45
    notes: "Getting started guide"
---

5-Minute Snapping

Time entries snap to 5-minute increments. This reflects how people actually think about time — “about 20 minutes” or “around 45 minutes” — without forcing false precision:

The clock-drag interface enforces this naturally. You drag around a clock face to set the duration, and the snapping happens as you drag — so the value you see is the value that gets saved.

Per-Task Entries

Single Task, Multiple Sessions

A task can have multiple time entries across different sessions and dates. Each entry is independent:

time_entries:
  - date: 2026-01-27
    duration: 60
    notes: "Morning session"
  - date: 2026-01-27
    duration: 45
    notes: "Afternoon session"
  - date: 2026-01-28
    duration: 30
    notes: "Final review"

Total: 2h 15m across 2 days

Linking to Projects

Time entries inherit the task’s project and tag metadata. When a task belongs to a project, all time logged against it rolls up into project-level reports automatically:

---
title: Write documentation
project: Product Launch
tags: [docs, writing]
time_entries:
  - date: 2026-01-27
    duration: 90
---

Reporting

By Project

Aggregates time across all tasks in a project for a given date range. If a task belongs to multiple projects, its time is split evenly across them:

By Tag

Same aggregation by tag. Useful for tracking time spent on categories of work (writing, meetings, code review) regardless of which project they belong to:

By Date

Day-by-day breakdown of total time logged, with per-task detail. Available in day, week (7-day), month (30-day), and custom range views:

Mon 27 Jan: 6h 45m
  └── Documentation (2h 15m)
  └── Code review (1h 30m)
  └── Meetings (3h 00m)

Tue 28 Jan: 7h 30m
  └── Feature development (4h 00m)
  └── Testing (2h 00m)
  └── Planning (1h 30m)

Best Practices

1. Log at end of task — Record time immediately after finishing a work session. Waiting until end-of-day reduces accuracy.
2. Use consistent notes — Short, repeatable labels like “draft,” “review,” or “client call” make reports more useful than free-form descriptions.
3. Review weekly — Glance at the weekly report to catch missing entries. Easier to backfill yesterday than last month.
4. Tag for reporting — Tags drive the “By Tag” report. If you want to know how much time goes to meetings vs deep work, tag consistently.