You've seen this bug. Maybe you've shipped it.

A user in New York selects December 5th on a date picker. They submit the form. The confirmation page shows December 4th.

What happened?

The Silent Timezone Disaster

User clicks December 5th. The calendar creates:

new Date('2024-12-05')
// JavaScript interprets as UTC midnight

On the user's machine in New York:

new Date('2024-12-05').toLocaleDateString()
// "12/4/2024" - WRONG!

December 5th UTC midnight is December 4th at 7pm in New York.

The frontend sends it to the server, the server stores it, and when it comes back... the user sees the wrong date.

Why AI Makes It Worse

Ask Claude to help with a date picker form:

// AI generates this (broken)
const handleSubmit = async (selectedDate: Date) => {
  await fetch('/api/events', {
    body: JSON.stringify({
      date: selectedDate.toISOString()  // Bug waiting to happen
    })
  })
}

The AI follows "best practices" (use ISO strings, store UTC) but produces wrong results.

The Solution: Whenny's Transfer Protocol

Whenny preserves timezone context across the wire:

import { createTransfer, fromTransfer } from '@/lib/whenny'

// FRONTEND: User picks December 5th
const payload = createTransfer(selectedDate, {
  timezone: Intl.DateTimeFormat().resolvedOptions().timeZone
})
// { iso: "...", originZone: "America/New_York", originOffset: -300 }

// SERVER: Receive and store
const received = fromTransfer(body.date)
await db.events.create({
  datetime: received.date,
  timezone: received.originZone,
})

// FRONTEND: Display correctly
whenny(event.datetime).md  // "Dec 5, 2024" ✓

Stop shipping the December 4th bug.

npx create-whenny
npx create-whenny add transfer timezone