Pikaday: A friendly guide to front-end date pickers
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, anddatalistacross Firefox/Safari, limiting reliance on native solutions.