Pikaday: A friendly guide to front-end date pickers

Original Article ↗ Hacker News Discussion ↗

Pikaday site and project status

  • Several commenters were initially confused, thinking this was a new JS datepicker release; others point out the GitHub repo is archived and explicitly says Pikaday is “probably not the right choice today.”
  • Clarification: the domain is being reused for a guide advocating native date/time inputs, not for promoting the old library. Some think this could have been made clearer.

Native vs custom date pickers

  • One camp argues native pickers are best: consistent with the OS, familiar over time, better for accessibility, less code and complexity.
  • Another camp says many OS/browser pickers are genuinely bad: hard to select distant years (especially birthdays), non-discoverable interactions (e.g., tappable year headings), ugly or brand-inconsistent, and inconsistent across browsers.
  • Some report real-world complaints from less tech-savvy users and switched to explicit text/dropdown combinations instead.

Context: what kind of date?

  • Strong agreement that context should dictate UI:
    • Birthdates and known dates → plain text fields or three separate inputs (day/month/year); often backed by UX research (e.g., GOV.UK patterns).
    • Travel, reservations, planning → calendar-style picker or week/month views to visualize ranges and weekends.
    • Many want richer native controls: week, month, multi-date, ranges, calendly-style slots.

Locales, formats, and international calendars

  • Native inputs respect browser/OS locale, but that may conflict with app-wide locale or user expectations (e.g., bilingual users, 24h vs 12h, mixed language/locale needs).
  • Confusion over formats like “3/9” remains; some insist locale settings don’t fully solve ambiguity.
  • Discussion notes that non‑Western calendars (e.g., Nepali, Ethiopian) are barely addressed by common pickers.

Time zones, DST, and future dates

  • Several warn that relative terms (“today,” “tomorrow,” “this time next month”) and cross-border or future scheduling are minefields: DST changes, shifting time zone rules, and local-vs-UTC semantics.
  • Debate around ISO 8601: it encodes offsets, not named zones, which can be problematic for future appointments where political time-zone changes may occur; RFC 9557-style extensions with zone IDs are mentioned.

Developer trade-offs and browser gaps

  • Some advocate “just use <input type="date"> or even plain text with clear placeholders,” to avoid endless edge cases.
  • Others note missing or inconsistent support for type="week", type="month", step, and datalist across Firefox/Safari, limiting reliance on native solutions.