[varun-pahuja]

What and why

Adds the Unix Timestamp conversion guide the SEO coverage engine asked for in #275: unix timestamp to date maps to the Timestamp Converter, and the guides collection had no entry for it. New GUIDES entry plus the page.tsx and opengraph-image.tsx routes, set up the same way as the existing guides.

Closes #275

How I tested this

• npm run lint — passes (0 errors; the 11 warnings are pre-existing)
• npm test — 998 passed (Node 22; the one failure seen under Node 26 is the known happy-dom/localStorage environment issue and also fails on clean develop)
• npm run build — passes; /guides/convert-unix-timestamp-to-date is built, listed in sitemap.xml, and its OG image route renders
• Verified every example in the guide by running it: the epoch table (0, -315619200, 946684800, 1700000000, 1792713600), the 2038 boundary 2147483647, digit counts for s/ms/µs/ns, both JavaScript snippets (Node) and both Python snippets (datetime with timezone.utc)
• Checked the quoted outputs against the tool source: unit thresholds match detectUnit in lib/time-utils.ts, the range limit matches MAX_DATE_MS (100,000,000 days ≈ 273,791 years), and the relative-time wording matches relativeTime in lib/jwt-utils.ts
• Checked --lime is defined in both themes (app/guides/... uses var(--lime) for the accent, steps, and CTA)

AI assistance

Claude Code — wrote the registry entry, guide page, and test runs. I verified the examples and claims against the tool source before opening this PR.

Type of change

• Bug fix
• New tool or feature
• Tests
• Refactor or cleanup
• Docs

Checklist

• I was assigned the linked issue
• npm run lint && npm run test && npm run build passes locally
• Logic changes live in lib/ and have a test in lib/__tests__/
• For a bug fix: the new test fails without my change
• No analytics, trackers, or calls that send user data off-device
• Works in both light and dark themes (if UI changed)
• Inputs have labels and it works with the keyboard alone (if UI changed)
• New tool: registry entry, page.tsx, client component, opengraph-image.tsx, and the bug report dropdown are all done

Notes for reviewers

• No new test file: lib/__tests__/guides.test.ts runs describe.each(GUIDES), so the new entry is picked up automatically for path, accent, metadata limits, JSON-LD, breadcrumb, and route existence — same as the other six guides.
• The seconds-vs-milliseconds section documents the real detectUnit edge case: millisecond values from 1970 to 1972 fall under the seconds threshold, so the guide tells readers to pick the unit explicitly for very old dates.
• The guide states the converter's actual range (MAX_DATE_MS, 100,000,000 days) rather than a rounded folklore number, and scopes the 2038 claim to 32-bit time_t and 32-bit integer epoch columns.

[anurag629]

Thanks @varun-pahuja, this is a solid guide: the page, OG image, sitemap entry and JSON-LD all work, lint, tests and build pass, and the tables, the 2038 boundary, the 100,000,000 day range and both code samples check out. A few facts need fixing:

1. The seconds vs milliseconds FAQ says a seconds value has had 10 digits "since 2001", but that only started on 2001-09-09 (1000000000), and the example right after it, 946684800 for January 1, 2000, has 9 digits (12 in milliseconds), so counting its digits gives the wrong answer. "Since September 2001" plus an example like 1700000000 and 1700000000000 fixes both.
2. Millisecond values stay under the 10^11 seconds threshold until 1973-03-03, so the caveat should say "1970 to early March 1973", not "1970 to 1972".
3. Step 5 and the last FAQ say the tool rejects impossible days like February 30. It does when the input starts with YYYY-MM-DD (hasImpossibleCalendarDay in lib/time-utils.ts), so 2024-02-30 is an error, but February 30, 2024 goes straight to Date.parse and comes out as March 1. Please say it for ISO dates, something like "2024-02-30 is rejected instead of rolling over".
4. Step 4 says every field has a copy button, but Relative time doesn't have one.
5. "an instant chosen as the starting point of Unix history" isn't right: Unix work started in 1969, and the first edition counted sixtieths of a second from 1971-01-01. 1970-01-01 came later as a round reference point, so just calling it the fixed reference point is enough.
6. Small one: Python prints tzinfo=datetime.timezone.utc in that repr, not tzinfo=timezone.utc.

If this merges after today, please move publishedAt to that day too.

[varun-pahuja]

@anurag629 Thanks for the careful review. All six points addressed:

1. FAQ seconds vs ms: Changed "Since 2001" → "Since September 2001" (10-digit seconds started 2001-09-09 at 1000000000) and swapped the example to 1700000000 (10 digits) / 1700000000000 (13 digits).

2. ms threshold caveat: Updated to "early March 1973" (10^11 ms = 1973-03-03) instead of "1972".

3. Impossible calendar days: Scoped to ISO dates in both Step 5 and the timezone FAQ — the check runs on hasImpossibleCalendarDay which only fires for YYYY-MM-DD inputs; written-out dates go through Date.parse and roll over.

4. Copy buttons: Step 4 now says "Every result field except Relative time has a copy button".

5. Epoch origin: Removed the "starting point of Unix history" claim; now says "the fixed reference point known as the epoch".

6. Python repr: Fixed the comment to show tzinfo=datetime.timezone.utc (what Python actually prints).

If this merges after today I'll bump publishedAt to the merge day (let me know or I'll watch for it).

All gates pass: lint 0 errors / 11 pre-existing warnings, 998 tests, build green, guide in sitemap.

[anurag629]

Thanks @varun-pahuja, all six are fixed and read well now. One tiny thing the edit left behind: a double comma after "(10^11 ms is 1973-03-03)". Once that's gone I'll merge.

[anurag629]

Suggested change

	enough to fall under the seconds threshold (10^11 ms is 1973-03-03),, so for very old dates choose
	enough to fall under the seconds threshold (10^11 ms is 1973-03-03), so for very old dates choose

[anurag629]

Hey @varun-pahuja, just the double comma left on this one (app/guides/convert-unix-timestamp-to-date/page.tsx, line 225, after "1973-03-03)"), then I'll merge it. Would be good to land it before the 31st.

[anurag629]

Hey @varun-pahuja, closing this one, since #275 went to someone else after five quiet days and the guide is now in with #397. Thanks for all the work you put into it, the fixes you made read really well.