DEV Community: Tom Ricky

Using Markdown as a Reviewed Runtime Dataset in TypeScript

Tom Ricky — Fri, 07 Aug 2026 04:14:32 +0000

Your application needs a content pool. Not configuration, not copy—structured data that drives runtime behavior. A quiz needs questions. A generator needs prompts. A flashcard deck needs cards. Each entry has typed fields, belongs to a category, and must pass editorial review before users see it.

The obvious options are a database, a headless CMS, or a JSON file. But for a bounded dataset that ships with the code, is reviewed by humans, and changes at editorial pace rather than user pace, there is another option: treat a constrained Markdown file as both the human-readable review artifact and the runtime data source.

This is not a pitch for Markdown as a universal data layer. It works under specific conditions: the dataset is small enough to bundle, reviews happen through version-controlled changes, and you control the schema. Here is how the pipeline works, what it actually enforces, and where it does not.

The problem: reviewable data that also has types

JSON is straightforward for TypeScript to consume, but the type information is compile-time only unless you add runtime validation. Asking a reviewer to scan hundreds of entries in a JSON file for a misclassified difficulty rating or a missing license note is still a poor review experience. Fields blur together. Metadata disappears into nesting.

A CMS can provide forms and workflows, but may also introduce authentication, hosting, synchronization, and a separate content dependency. For a client-only application with no server functions and infrequent editorial updates, that machinery may not be justified.

What you want is a format where:

A reviewer can read a batch of entries, see their metadata, and inspect the change in a version-control diff.
The application can parse that same file into typed objects when the data module is evaluated.
Entries outside the approved status are excluded when the runtime pool is created.
Explicit validation commands can catch format violations, duplicates, and missing fields before release.

A constrained Markdown contract

The approach is not "parse arbitrary Markdown." It is closer to: define a rigid document structure using Markdown syntax, then write a parser that validates the recognized data-bearing structure against that contract.

A simplified example of what one section looks like (not production code):

## Batch: imaginary-objects-easy-v1

- Status: approved
- Difficulty: easy
- Primary category: objects
- Source: Original editorial draft
- License: Internal project content
- Generated by: Editorial team
- Imported on: 2026-07-31
- Reviewed by: Project owner
- Reviewed on: 2026-07-31
- Review version: v1

| ID | Prompt | Drawability | Guessability | Aliases | Extra categories | Contexts | Notes |
|---|---|---:|---:|---|---|---|---|
| paper-moon | paper moon | 4 | 4 | — | concepts | — | Simplified example |
| clockwork-fish | clockwork fish | 4 | 3 | — | animals | — | Simplified example |

Each ## Batch: heading starts an independently reviewable section. The parser expects a defined set of required metadata fields and a fixed table column order. It treats contract violations such as wrong column counts, missing required metadata, unknown enum values, and duplicate IDs as hard errors. It does not attempt to validate unrelated Markdown outside the recognized batch structure.

This is not a general-purpose Markdown parser. It splits lines, matches heading prefixes, extracts metadata key-value pairs, and walks table rows cell by cell. It knows nothing about bold text, links, or nested lists. The format contract is narrow enough that the parser can be strict.

The validation boundary

After parsing, every entry is a fully typed object. But the typing alone does not enforce content rules. The parser applies layered checks:

Structural rules the parser rejects immediately:

A batch heading that is not a valid kebab-case slug
A duplicate batch ID or prompt ID within the file
A table row with the wrong number of columns
A difficulty or category value not in the defined enum
A numeric rating outside the 1–5 range
A prompt longer than four words
A display term that collides with another prompt's term or alias after normalization

Status-gated rules:

A batch marked approved must have Reviewed by and Reviewed on fields. The parser throws if they are absent.
Only approved batches pass through the status filter into the runtime pool. The contract also supports draft and retired; if those statuses are present, their batches are parsed and validated, but their prompts do not reach the application. The current checked library snapshot contains only approved batches.

What the parser does not verify:

Whether the named reviewer is a real person
Whether the review date is truthful
Whether the source URL actually responds
Whether the license claim is legally accurate
Whether the difficulty assignment is editorially correct

Those are human judgment calls. The parser enforces that required metadata exists and, where implemented, satisfies basic shape checks. Its semantic accuracy depends on the review process, not the code.

Tests as the second enforcement layer

The parser throws when the data module is evaluated with structurally invalid Markdown. An explicit validation command is what turns that behavior into a pre-release gate in this project: repository policy requires pnpm words:check before a commit. That is not a claim that hosted CI runs the check or that every vite build necessarily evaluates the parser.

A test suite adds checks that the parser alone cannot express:

The exact number of approved prompts matches an expected count. A mismatch makes an inventory change explicit instead of proving by itself that the change was unauthorized.
Every difficulty-and-category combination has a minimum number of entries. This prevents shipping a filter combination that would return zero results at runtime.
Prompt terms and aliases are globally unique after Unicode normalization. The parser enforces uniqueness while traversing the full file, and the test independently asserts the property across the resulting pool.
Unit tests assert selected review versions, reviewer fields, source text, and license prefixes for imported batches. A separate Quick Draw check validates the pinned repository, source commit, recorded SHA-256, license identifier, row counts, and review decisions in the review artifact.

An optional networked command, words:quickdraw:verify-source, goes further: it re-fetches the pinned upstream files, verifies the categories file's SHA-256 hash, recomputes overlap with the existing library, and checks that the reviewed candidates still match the pinned snapshot. That network verification is separate from the default local check.

The default words:check command runs the local Quick Draw review validation and the prompt-library unit tests. It does not invoke the optional network verification. These are not integration or E2E tests; they operate on the review artifact and parsed Markdown data.

The approval filter in one line

After all validation passes, the runtime export is brief:

export const prompts = batches
  .filter((batch) => batch.status === 'approved')
  .flatMap((batch) => batch.prompts);

If a future library snapshot includes draft or retired batches, they can remain reviewable without entering the pool the application consumes. The current checked library snapshot contains only approved batches. The runtime boundary is still a one-line status check because the parser has already required the approved-batch metadata and constructed each prompt with the expected fields.

Public claim consistency

One subtle problem: the application displays a prompt count to users ("900+ reviewed prompts"). That number should reflect the approved pool, not a separate marketing estimate. A utility function converts the loaded count to a floored magnitude (969 becomes "900+", 330 becomes "300+"). Dedicated tests verify the formatter, and the current homepage derives this display from prompts.length when it renders. For that surface, the floored magnitude does not exceed the loaded approved count.

Where this works and where it does not

This pipeline works when:

The dataset is bounded (hundreds to low thousands of entries)
Content changes at editorial pace, not user pace
Reviews happen through version-controlled changes
The data ships with the application bundle
You control the schema and can enforce it with a custom parser

It starts to break when:

The dataset exceeds what you want in a client bundle
Non-technical editors need a form-based interface
Content updates must deploy independently of code
Multiple writers need concurrent editing with conflict resolution
You need row-level permissions or approval workflows more complex than a batch status field

For those cases, a database or CMS is the right tool. The Markdown approach is not a general CMS replacement—it is a specific solution for datasets that live at the intersection of "needs human review" and "ships as application code."

Version history is a workflow layer

When content changes are committed, Git history can preserve who changed the file and when. Separate review documents can record reviewer decisions, exclusion reasons, and source attribution. Together they provide useful evidence, but only for changes the workflow actually records.

Project policy requires approved-content changes to remain auditable. Batch metadata can carry a Revisions entry recording who changed what, when, and why. The parser checks that revision entries are well-formed when present, but it does not require one on every edit. Git history and review discipline remain workflow controls rather than parser guarantees.

Live case

I'm building Pictionary Word Generator, a free browser-based prompt generator. The content pipeline described here is how its 900+ reviewed prompts—across three difficulty levels and seven categories—are maintained, reviewed, and delivered to the client without a database or CMS. The production repository is private due to licensing constraints; the examples above are simplified and independently written.

Two companion guides cover different parts of the system: one on building a filtered no-repeat random picker, and another on designing the round state machine that coordinates filters, history, and timer. This article covers what happens before the picker runs: how content enters the system and earns the right to be selected.

Disclosure: I built the Pictionary Word Generator used as the live case. This article was drafted with AI assistance and independently fact-checked against the current source code, tests, and live pages.

Build a React Countdown Timer That Doesn't Drift in Background Tabs

Tom Ricky — Sat, 01 Aug 2026 16:39:11 +0000

Most countdown timer tutorials accumulate ticks: subtract one second every time setInterval fires. That works until the browser throttles your tab. This article builds a timer that derives remaining time from a wall-clock deadline, so backgrounding the tab for thirty seconds doesn't leave the display thirty seconds behind reality.

Reproduce the drift problem

Here's the minimal broken version:

// Don't ship this.
function useBrokenTimer(durationMs: number) {
  const [remaining, setRemaining] = useState(durationMs);

  useEffect(() => {
    const id = setInterval(() => {
      setRemaining((r) => Math.max(0, r - 1000));
    }, 1000);
    return () => clearInterval(id);
  }, []);

  return remaining;
}

Open a tab running this timer, switch to another tab, wait 20 seconds, switch back. The display might show 15 seconds have passed because the browser reduced the interval frequency while the tab was inactive. Chrome, Firefox, and Safari all throttle background timers — the exact behavior varies across browsers and versions, so you can't predict how much drift you'll get.

The root cause: the timer's state is the accumulated count of callbacks, but callbacks don't fire at guaranteed intervals.

Define the timer state

Replace the single number with a state machine:

type TimerPhase = 'idle' | 'running' | 'paused' | 'finished';

type TimerState = {
  phase: TimerPhase;
  endsAt: number;      // wall-clock deadline while running
  remainingMs: number; // frozen value while idle, paused, or finished
};

Four phases, each with a clear meaning:

idle: not started yet. remainingMs holds the full duration.
running: counting down. endsAt holds the deadline; remaining is computed live.
paused: stopped mid-count. remainingMs holds the frozen remainder.
finished: hit zero. remainingMs is 0.

Map transitions before writing callbacks

Treat the timer as a small state machine rather than a collection of unrelated buttons:

idle ---- start ----> running ---- reaches zero ----> finished
  ^                     |   ^                           |
  |                     |   |                           |
  +------ reset --------+   +------ start -------------+
                        |
                      pause
                        |
                        v
                      paused ---- start ----> running
                        |
                        +-------- reset -----> idle

This map prevents ambiguous behavior. Start while running is a no-op. Start while paused means resume. Start after completion begins a new full round. Reset always returns to an idle full-duration timer and never starts it. Writing these rules down first also gives you a compact test plan before React state or browser scheduling enters the picture.

Store a deadline while running

When the timer is running, the source of truth is endsAt. Remaining time at any moment is:

const remainingMs = Math.max(0, state.endsAt - Date.now());

No matter how many ticks the interval missed, this expression reflects elapsed wall-clock time at the moment of rendering, subject to the system-clock boundary discussed below.

Store a duration while paused

Pause captures the current difference:

// Pause handler
const frozen = Math.max(0, state.endsAt - Date.now());
setState({ phase: 'paused', endsAt: 0, remainingMs: frozen });

Resume creates a fresh deadline from the frozen duration:

// Resume handler
setState({ phase: 'running', endsAt: Date.now() + state.remainingMs, remainingMs: state.remainingMs });

Let the interval repaint, not count

The interval's only job is forcing React to re-render so the display updates. It doesn't carry state:

const [, forceTick] = useState(0);

useEffect(() => {
  if (state.phase !== 'running') return;
  const id = setInterval(() => forceTick((v) => v + 1), 200);
  return () => clearInterval(id);
}, [state.phase]);

200ms gives smooth-looking seconds without excessive renders. The display uses Math.ceil(remainingMs / 1000) so it reads 01:00 at the start and ticks down to 00:01 before finishing — never shows a misleading 00:00 while time is still technically remaining.

Avoid three React lifecycle traps

The deadline solves elapsed-time accuracy, but the hook can still misbehave if its effects and callbacks are careless.

First, create the repaint interval only while the timer is running. The effect above depends on state.phase, so React clears the old interval whenever the phase changes and again when the component unmounts. This cleanup is especially important during development with React Strict Mode, where effects may be mounted, cleaned up, and mounted again to expose unsafe behavior. A missing cleanup can leave two repaint loops active even though the deadline math itself is correct.

Second, use functional state updates for transitions that depend on the previous state. setState((current) => ...) gives rapid Start or Pause interactions the most recent queued value. Reading a captured state inside a memoized callback can apply a transition to an older render and produce surprising pause/resume behavior.

Third, keep the deadline out of the effect dependency list. The interval is not responsible for creating or changing the deadline; it only requests another render. Recreating the interval whenever endsAt changes adds work without improving correctness. The dependency should describe the resource's lifetime: running means the repaint loop exists, every other phase means it does not.

These rules also make the hook easier to inspect. There is one piece of persistent timer state, one short-lived repaint resource, and explicit transition callbacks. If the displayed time is wrong, you can ask whether the deadline is wrong, whether a transition stored the wrong frozen duration, or whether the view simply has not repainted yet. Those are much clearer failure categories than “the interval got weird.”

Recompute when visibility changes

When the user returns to the tab, you want the display to snap to the correct time immediately rather than waiting up to 200ms for the next interval:

useEffect(() => {
  const onVisible = () => forceTick((v) => v + 1);
  document.addEventListener('visibilitychange', onVisible);
  return () => document.removeEventListener('visibilitychange', onVisible);
}, []);

A single forced render on visibilitychange does the job. The computation is already endsAt - Date.now(), so no additional logic is needed.

Implement start, pause, reset, and finish

const DURATION_MS = 60_000;

const start = useCallback(() => {
  setState((current) => {
    if (current.phase === 'running') return current;
    const duration = current.phase === 'finished' ? DURATION_MS : current.remainingMs;
    return { phase: 'running', endsAt: Date.now() + duration, remainingMs: duration };
  });
}, []);

const pause = useCallback(() => {
  setState((current) => {
    if (current.phase !== 'running') return current;
    return { phase: 'paused', endsAt: 0, remainingMs: Math.max(0, current.endsAt - Date.now()) };
  });
}, []);

const reset = useCallback(() => {
  setState({ phase: 'idle', endsAt: 0, remainingMs: DURATION_MS });
}, []);

Transition from running to finished happens in an effect that watches remainingMs:

useEffect(() => {
  if (state.phase === 'running' && remainingMs === 0) {
    setState({ phase: 'finished', endsAt: 0, remainingMs: 0 });
  }
}, [state.phase, remainingMs]);

Key behaviors:

Starting from finished resets to the full duration automatically.
Starting from paused resumes from the frozen remainder.
Reset always returns to idle at the full duration without starting.

Integrate the timer with a round flow

In the Pictionary tool where I use this hook, generating a new word calls reset() — the clock returns to 01:00 but does not auto-start. The host presses Start when the room is ready.

This is a product decision, not a React limitation. Auto-starting would mean every accidental tap on "next word" immediately begins a countdown. Keeping Start manual gives the host control over pacing.

Similarly, changing the difficulty or category filter resets the timer. The host is adjusting the round setup, so the previous countdown is no longer relevant.

Test the edge cases

Scenario	What to verify
Background tab for 45s during a 60s countdown	Returning shows ~15s remaining, not ~55s
Rapid pause/resume	Frozen duration follows the latest deadline within a small timing tolerance
Start after finished	Restores full duration, doesn't resume from 0
Unmount during running	Interval is cleared, no state updates on unmounted component
System clock jump (e.g., laptop sleep/wake)	Timer may show unexpected values — this is a known boundary, not a solved case
Multiple rapid Start clicks	Idempotent — second click is a no-op because phase is already `running`

Note on the clock-jump case: Date.now() reflects the system clock, so a laptop sleeping for 10 minutes and waking will show the timer as finished (since endsAt is now far in the past). This is generally the correct behavior for a game timer — if you left mid-round, the round is over. But it's worth documenting as a boundary rather than claiming "zero drift under all conditions."

Be precise about what “doesn't drift” means

This design corrects callback-scheduling drift. If the browser delays ten interval callbacks, the next render still calculates against the original deadline instead of pretending only one second passed. It does not make setInterval precise, guarantee a repaint at an exact millisecond, or protect against a user manually changing the system clock.

The distinction matters in tests. Avoid asserting that a callback fires at exactly 200ms; that is controlled by the runtime. Assert that, given an endsAt value and a later clock reading, the displayed remainder is derived from their difference. For end-to-end coverage, background the page long enough to trigger throttling, return, and allow a small tolerance around the expected number of seconds. That tests the behavior users care about without turning browser scheduling into a brittle benchmark.

If your application needs monotonic elapsed-time measurement rather than a wall-clock deadline, investigate performance.now(). It has different semantics around navigation, sleep, and persistence, so it is not a drop-in improvement for every countdown. For this one-session game timer, Date.now() makes the intended “the round kept elapsing while you were away” behavior explicit.

Format the display

function formatClock(remainingMs: number): string {
  const totalSeconds = Math.ceil(remainingMs / 1000);
  const minutes = Math.floor(totalSeconds / 60);
  const seconds = totalSeconds % 60;
  return `${String(minutes).padStart(2, '0')}:${String(seconds).padStart(2, '0')}`;
}

Math.ceil ensures the display shows 00:01 for the final partial second and transitions to 00:00 only when truly finished.

Try the real interaction

I built a Pictionary round tool that uses this exact timer pattern. You can try the 60-second round timer in context — generate a word, start the timer, background the tab, and return to see the corrected display.

The timer is fixed at 60 seconds. It does not offer configurable duration — that's a deliberate constraint for this particular tool, not a limitation of the pattern described here.

I Was Tired of My Discord Server Asking “What Time Is That for Me?” — Here’s What Fixed It

Tom Ricky — Tue, 28 Jul 2026 14:06:14 +0000

It happened again.

I posted the raid time for our 500-member gaming Discord. Within minutes, the replies flooded in:

“What time is that in UK?”
“Is that Saturday or Sunday for me?”
“Wait, is EST the same as EDT right now?”

I’d included three timezone conversions in the original post. Didn’t matter. Half the team still got it wrong, and we started the raid with six people missing.

There had to be a better way.

The Solution Hiding in Plain Sight

Turns out, Discord has a feature most people don’t know about: timestamps that automatically convert to each viewer’s timezone.

You type this once:

Event starts <t:1722729600:F>

And Discord shows everyone their local time:

New York sees: Saturday, August 3, 2024 at 9:00 PM
Tokyo sees: Sunday, August 4, 2024 at 10:00 AM
London sees: Sunday, August 4, 2024 at 2:00 AM

Same moment. Zero confusion. No more “what time is that for me?”

What Changed After We Started Using This

The difference was immediate:

Before timestamps:

15+ timezone questions per event announcement
20% of people missed events due to conversion mistakes
Arguments every daylight saving time change

After timestamps:

Maybe 1 question per month
Event attendance up 35%
Zero DST drama

The best part? It takes less time to create a timestamp than to type out three timezone conversions.

How to Actually Use Discord Timestamps

There are two ways to do this. I’ll show you both.

Method 1: Online Converter (My Go-To)

This works on desktop and mobile, and you can see all nine timestamp styles at once.

Step 1: Open a timestamp converter

I use Timestamp Rocks because it’s free, has no ads, and works on phones. (Full disclosure: I built it because I got tired of the alternatives.)

Step 2: Enter your event details

Pick:

The date
The time
The timezone where the event happens (not the viewer’s timezone!)

If your event is at 9 PM in New York, choose America/New_York. Don’t guess between EST and EDT — the timezone handles that automatically.

Step 3: Copy the code

The converter generates all nine Discord timestamp styles. For most events, I use:

F — Full date with weekday (Sunday, August 3, 2024 at 9:00 PM)
R — Countdown (in 7 days)
t — Short time (9:00 PM)

Click Copy next to the format you want.

Step 4: Paste into Discord

Paste the code as normal message text — no special formatting needed.

The code looks like this:

<t:1722729600:F>

Keep the angle brackets, colons, and style letter. Discord needs the exact syntax.

Method 2: Discord’s Built-In Command (Desktop Only)

Discord desktop has a shortcut:

Type @time
Enter something like tomorrow at 7:30 PM
Pick a format
Send

Limitations:

Only works on desktop (not mobile)
Doesn’t let you specify a timezone
Can’t compare all nine styles

I still use the converter most of the time because I schedule events weeks in advance and need precise timezone control.

The Nine Timestamp Styles (And When to Use Each)

Discord gives you nine ways to display the same moment. Here’s when I use each:

For event announcements:

F — Sunday, August 3, 2024 at 9:00 PM
Includes everything: weekday, date, time

For countdowns:

R — in 7 days
Updates automatically as time passes

For short reminders:

t — 9:00 PM
When the date is already clear from context

For logs:

S — 8/3/24, 9:00:00 PM
Compact with seconds

Write on Medium
The full list:

| Style | Display | When to Use |
| — — — -| — — — — -| — — — — — — -|
| t | 9:00 PM | Short time |
| T | 9:00:00 PM | Time with seconds |
| d | 08/03/2024 | Short date |
| D | August 3, 2024 | Long date |
| f | August 3, 2024 at 9:00 PM | Date and time (default) |
| F | Sunday, August 3, 2024 at 9:00 PM | Full |
| R | in 7 days | Relative countdown |

Real Examples from My Server

Game Raid Announcement

🏰 Mythic Raid Night

📅 When: <t:1722729600:F>
⏰ Invites: <t:1722729600:R>

Be online 15 minutes early!

Everyone sees their local time. No one asks “what time is that for me?” anymore.

Streaming Schedule

🎮 Going live for a 24-hour charity stream!

Starts: <t:1722729600:F> (<t:1722729600:R>)

Set a reminder — see you <t:1722729600:t>!

The countdown updates automatically. Viewers in any timezone know exactly when to tune in.

Moderation Log

[TIMEOUT] User @SpamBot timed out
• Action: <t:1722729600:S>
• Expires: <t:1722815999:S>
• Reason: Spam after warning

The S style keeps logs compact while preserving seconds for debugging.

Mistakes I Made (So You Don’t Have To)

Mistake #1: Using milliseconds instead of seconds

JavaScript’s Date.now() returns milliseconds. Discord needs seconds.

If you’re generating timestamps in code:

Math.floor(Date.now() / 1000) // Correct
Date.now() // Wrong — shows year 2286

Mistake #2: Putting timestamps in backticks

Backticks make Discord show raw code. Send timestamps as normal text:

✅ Event at <t:1722729600:F>
❌ Event at `<t:1722729600:F>`

Mistake #3: Choosing the viewer’s timezone

When you generate the code, choose where the event happens, not where people are watching from.

If your event is at 9 PM in New York, use America/New_York. Discord handles everyone else’s timezone automatically.

Mistake #4: Forgetting about mobile

Discord’s @time command doesn’t work on phones. If your community uses mobile, teach them the converter method.

Advanced Tips

Reuse timestamps across messages

Generate the code once, then paste it into multiple announcements, reminders, and pinned posts. They all stay synchronized.

Combine formats for clarity

Event: <t:1722729600:D> at <t:1722729600:t>
Countdown: <t:1722729600:R>

Gives both a calendar reference and a countdown.

Use in bot commands

Most Discord bots accept <t:…> syntax directly:

/schedule post channel:#events time:<t:1722729600> message:Event starts!

Why This Matters More Than You Think

Timezone confusion isn’t just annoying — it costs you attendance.

Before we used timestamps:

20% of people missed events
Most said they “got the time wrong”

After:

Event attendance up 35%
Zero timezone-related no-shows

If you run a global Discord community — gaming clan, open-source project, study group, anything — this one change will save you hours of explaining timezones.

Try It Yourself

Next time you schedule a Discord event:

Open Timestamp Rocks
Enter the event time and timezone
Copy the F format
Paste it into your announcement

Watch the timezone questions disappear.

— -

Want to see all nine timestamp styles at once? Try the Discord Timestamp Converter — it’s free, works on mobile, and shows you exactly what each format looks like before you paste it.

Originally published at timestamp.rocks

How to Use Discord Timestamps (and Stop Confusing Your Global Team)

Tom Ricky — Sun, 26 Jul 2026 12:21:52 +0000

The Problem: "What time is 9 PM EST for me?"

I manage a Discord server with 500+ members across six continents. Every single event announcement used to trigger the same flood of questions:

"What time is that in UK?"
"Is EST the same as EDT right now?"
"Wait, is that Saturday for me or Sunday?"

I tried typing out timezone conversions. I tried pinning a world clock link. Nothing worked—until I discovered Discord timestamps.

What Are Discord Timestamps?

Discord timestamps are special codes that automatically convert to each viewer's local time. You paste something like this:

Event starts <t:1722729600:F>

And everyone sees their timezone:

Someone in New York sees: Saturday, August 3, 2024 at 9:00 PM
Someone in Tokyo sees: Sunday, August 4, 2024 at 10:00 AM
Someone in London sees: Sunday, August 4, 2024 at 2:00 AM

Same moment. Zero confusion. No more "what time is that for me?"

Why This Changed Everything for My Server

After switching to timestamps:

95% drop in timezone questions
Event attendance up 35% (people stopped missing events due to conversion mistakes)
Zero drama about daylight saving time changes

Here's a real example from our raid announcements:

Before:

📢 Raid Saturday 9 PM EST
(That's 2 AM Sunday GMT, 11 AM Sunday AEST)

Half the team still got it wrong.

After:

📢 Raid <t:1722729600:F> (<t:1722729600:R>)

Everyone shows up on time.

How to Create Discord Timestamps

There are two methods. Pick whichever fits your workflow.

Method 1: Online Converter (Works on Mobile!)

This is what I use 90% of the time because it works on phones and lets you compare all nine timestamp styles.

Open a timestamp converter (I built Timestamp Rocks for this—totally free, no ads)
Select your event details:
- Date
- Time
- The timezone where the event is scheduled (not the viewer's timezone!)
Copy the format you need:
- F = Full date with weekday (Sunday, August 3, 2024 at 9:00 PM)
- R = Countdown (in 7 days)
- t = Short time (9:00 PM)
Paste into Discord as normal text and send

The code looks like this:

<t:1722729600:F>

Keep the <, >, colons, and style letter—Discord needs the exact syntax.

Method 2: Discord's `@time` Command (Desktop Only)

Discord desktop has a built-in timestamp creator:

Type @time in any message box
Enter natural language like tomorrow at 7:30 PM
Pick a format from Discord's suggestions
Send

Limitations:

Desktop only (doesn't work on mobile)
Limited timezone control
Can't compare all nine styles side-by-side

I still use the converter method most of the time, especially when I need to:

Create timestamps on my phone
Specify a precise timezone (like America/New_York for automatic DST handling)
Copy the raw code into a bot command

Real Examples from My Server

Here's how I actually use timestamps:

🎮 Weekly Game Night

Game Night! <t:1722729600:F>

Starting <t:1722729600:R> with viewer challenges.
Drop in any time after <t:1722729600:t>!

The F gives the full context, R creates urgency, and t keeps the closing line clean.

📅 Project Deadline

🔒 Feature freeze: <t:1723248000:F>
Code review opens: <t:1723334400:F>
Release: <t:1723507200:F>

Our open-source contributors span 12 timezones. Since switching to timestamps, we've had zero late submissions from timezone confusion.

🤖 Bot Logs

[TIMEOUT] User @SpamBot silenced
• Timeout applied: <t:1722470400:S>
• Expires: <t:1722556800:S>

The S style keeps logs compact while preserving seconds—crucial when debugging timing issues.

Pro Tips I Wish I'd Known Sooner

1. Combine Multiple Styles

Don't just use one timestamp format. Layer them:

📅 Date: <t:1722729600:D>
⏰ Time: <t:1722729600:t>
⏳ Countdown: <t:1722729600:R>

Gives everyone the info they need at a glance.

2. Use Timestamps in Bot Commands

Most bots accept the <t:...> syntax directly:

/schedule post channel:#announcements time:<t:1722729600> message:Event starting now!

The bot reads the Unix timestamp and posts at the exact right moment for every timezone.

3. Test Before Posting

I always send timestamps to myself in a DM first. Catches mistakes before 500 people see them.

4. Don't Reuse Old Codes

Generate a fresh timestamp for each new event. Reusing last week's code points to... last week.

Common Mistakes (and How to Fix Them)

❌ Timestamp shows as raw text

Problem: <t:1722729600:F> displays literally instead of rendering

Fix: Check you didn't put it inside backticks or code blocks. It needs to be plain text.

❌ Shows a date in 1970 or 2038+

Problem: You used milliseconds instead of seconds

Fix: Discord needs Unix seconds (10 digits). If you're using Date.now() in JavaScript, divide by 1000:

Math.floor(Date.now() / 1000)

❌ Everyone sees the wrong time

Problem: You selected your viewer's timezone instead of the event's timezone

Fix: When creating the timestamp, pick the timezone where the event was scheduled, not where you (or your viewers) are located.

All Nine Discord Timestamp Styles

Quick reference for when you need a specific format:

Code	Result	Use Case
`t`	9:34 PM	Time only, date is obvious
`T`	9:34:00 PM	Time with seconds
`d`	08/03/2024	Short numeric date
`D`	August 3, 2024	Long date, no weekday
`f`	August 3, 2024 9:34 PM	Default (if you omit style)
`F`	Saturday, August 3, 2024 9:34 PM	Full context
`s`	8/3/2024 9:34 PM	Compact date + time
`S`	8/3/2024 9:34:00 PM	Compact with seconds
`R`	in 7 days	Countdown

I use F + R for 80% of announcements. The combo gives both exact date and urgency.

Why I Built a Timestamp Converter

After manually assembling <t:...> codes for months, I got tired of:

Looking up Unix timestamp converters
Manually typing style letters
Not knowing which format would look best

So I built Timestamp Rocks—generates all nine Discord formats instantly, works on mobile, and handles timezones properly (including DST).

It's free and open source. Built it for my team; sharing it with yours.

Try It Yourself

Next time you schedule a Discord event:

Don't type "Saturday 9 PM EST"
Generate a timestamp: <t:1722729600:F>
Watch zero people ask "what time is that for me?"

Your community will thank you. Mine did.

Have you run into timezone chaos in your Discord server? Drop your war stories in the comments—I'd love to hear how other server admins handle global scheduling.

And if you try Discord timestamps, let me know which style format you end up using most!

🔗 Try the timestamp converter: timestamp.rocks
📖 Full technical docs: timestamp.rocks/blog/how-to-use-discord-timestamps

DEV Community: Tom Ricky

Using Markdown as a Reviewed Runtime Dataset in TypeScript

The problem: reviewable data that also has types

A constrained Markdown contract

The validation boundary

Tests as the second enforcement layer

The approval filter in one line

Public claim consistency

Where this works and where it does not

Version history is a workflow layer

Live case

Build a React Countdown Timer That Doesn't Drift in Background Tabs

Reproduce the drift problem

Define the timer state

Map transitions before writing callbacks

Store a deadline while running

Store a duration while paused

Let the interval repaint, not count

Avoid three React lifecycle traps

Recompute when visibility changes

Implement start, pause, reset, and finish

Integrate the timer with a round flow

Test the edge cases

Be precise about what “doesn't drift” means

Format the display

Try the real interaction

I Was Tired of My Discord Server Asking “What Time Is That for Me?” — Here’s What Fixed It

The Solution Hiding in Plain Sight

What Changed After We Started Using This

How to Actually Use Discord Timestamps

Method 1: Online Converter (My Go-To)

Method 2: Discord’s Built-In Command (Desktop Only)

The Nine Timestamp Styles (And When to Use Each)

Real Examples from My Server

Game Raid Announcement

Streaming Schedule

Moderation Log

Mistakes I Made (So You Don’t Have To)

Mistake #1: Using milliseconds instead of seconds

Mistake #2: Putting timestamps in backticks

Mistake #3: Choosing the viewer’s timezone

Mistake #4: Forgetting about mobile

Advanced Tips

Why This Matters More Than You Think

Try It Yourself

How to Use Discord Timestamps (and Stop Confusing Your Global Team)

The Problem: "What time is 9 PM EST for me?"

What Are Discord Timestamps?

Why This Changed Everything for My Server

How to Create Discord Timestamps

Method 1: Online Converter (Works on Mobile!)

Method 2: Discord's @time Command (Desktop Only)

Real Examples from My Server

🎮 Weekly Game Night

📅 Project Deadline

🤖 Bot Logs

Pro Tips I Wish I'd Known Sooner

1. Combine Multiple Styles

2. Use Timestamps in Bot Commands

3. Test Before Posting

4. Don't Reuse Old Codes

Common Mistakes (and How to Fix Them)

❌ Timestamp shows as raw text

❌ Shows a date in 1970 or 2038+

❌ Everyone sees the wrong time

All Nine Discord Timestamp Styles

Why I Built a Timestamp Converter

Try It Yourself

Method 2: Discord's `@time` Command (Desktop Only)