Pikaday: A friendly guide to front-end date pickers
106 comments
·November 11, 2025abanana
HugoTea
The Gov.uk design team published research around data entry for dates https://designnotes.blog.gov.uk/2013/12/05/asking-for-a-date... Ultimately they found the best experience was three text boxes, day, month and year. They also have this "pattern" for helping with implementation https://design-system.service.gov.uk/patterns/dates/
bigfudge
It’s not just old people that suffer. I’m slightly ashamed to admit I started the 100-tap process when I first used that input before realising it was dumb and googling what to do. They really are bad.
padjo
Why were you using a calendar picker for a date of birth?
abanana
Could you explain what you mean? We're talking about the OS-native datepicker, which pops up when a user clicks on an HTML <input type="date">.
folmar
This is the place where the date picker does not help the user at all. It's easier to type the, presumably memorized, date, than to look it up in the calendar no matter how nice and handy the calendar is. Sure it does solve validation problem. Or maybe not correctly, don't ask about locales and date adjustments.
padjo
Using a calendar picker to input dates that users have memorised and are in the distant past is an awful experience. This is a pet peeve of mine.
kmoser
> Travel booking often has a fixed schedule with limited time options, such as every 15 minutes. Relative dates like “Today” and “Tomorrow” can be easier to understand.
Except when you're booking a flight and you're not sure whether "today" is based on your local time, the server's local time, or GMT. (I often book flights right about midnight and find words like "today" and "tomorrow" to be completely confusing.)
jandrese
> Relative dates like “Today” and “Tomorrow” can be easier to understand.
This is one of those ideas that sounds like a good idea on paper, but can be an actual nightmare to implement. There are so many edge cases that can occur that you need to think about, especially once you get into cases like "this time next month". What if daylight savings time trips? What about time zones? What if it is January 31st and you want something a month from now? What if it is 12:05 at night and someone asks for 4PM tomorrow?
You should think long and hard before offering relative time options in program.
cryptoz
Montreal public transit times used to be on some kind of like, 28-hour clock. Bus times after midnight would be labelled 27:30 or something. Suuuper confusing. It sounds so bizarre in fact, that I'm doubting my memory a bit, but I'm certain it was like that (say around 2006 or so).
evertheylen
This is actually how GTFS (a standard format for public transit data) works: https://gtfs.org/documentation/schedule/reference/#stop_time... . Especially sleeper trains can get weird with 30+ hours. But I don't think it's wise to show that to the user
1718627440
And it is the right thing to do as otherwise the question to which day a train belongs will be confusing. Just take it %24hours before intersecting trains.
It is also how I personally record time spans. It makes it much easier as you do not need to deal with the case where the start is larger than the end time and you can only have a single date field.
ChadNauseam
I've seen this in Japan as well. A store that's open from, let's say, 8am to 1am will actually advertise itself as being open from 8am to 25pm. I guess the perception is that it's confusing to have a range where the smaller number comes before the bigger number.
makeitdouble
Japanese are used to it because TV shows etc. that have the same issue.
If it airs at 2025-11-24 01:00, people will have an easier time to remember it's at a very late after the 23th's midnight, than a crazy early time on the 24th. Most TV or movie guide will show it as 25:00 on the 23th.
solidsnack9000
I think it is more common for them to write 8:00 to 25:00 - omitting AM and PM.
SoftTalker
Maybe at that point they should say "Closed 1am to 8am" instead.
pasc1878
UK buses and trains do this.
I think the reason is for Day return tickets ie those where you can go out and come back on the same day. It allows the return to be after midnight which makes sense for example going to a theatre show or pub that shuts at 11pm
dotancohen
I work with a factory that uses 32 hour timestamps, as some employees work a night shift.
parpfish
i hate that computers define 'today' and 'tomorrow' on days centered on midnight.
several times this has lead to problems when i'm doing a late-night work binge that cross into 12am and i see relative date terms that confuse me.
if you're out with some friends and it's 12:15 AM and you say "i really need to go, i have a big day tomorrow" it's understood that that means the big day is on this calendar date but after i wake up and NOT the following day.
cubefox
> Except when you're booking a flight and you're not sure whether "today" is based on your local time, the server's local time, or GMT.
But the same issue exists with explicit dates like "November 12".
kmoser
Not really, because the standard in air travel is that departure and arrival dates and times are always local to the departure or arrival airport, regardless of where you are when you book the flight (or what time it is locally when you book).
Muromec
After dealing with datepickers for (checks notes) two decades, my best advice is to use the damn input type text with a placeholder showing a format, then saving it as a string in whatever that ISO that makes sense is called.
Everything else is asking for endless trouble and pain with browsers, a11y, locales and what not. Also, may the God allmerciful save you from the cancer that custom components are, let whoever invented this wipe his ass with fiberglass insulation for the end of times.
Don't get fancy and you will not fall down 10 rabbit holes that datepickers are.
tshaddox
That’s probably fine for dates that people have memorized, like their birthday. But it’s certainly not great for something like flight search, where I might know I want to leave in early April on a Friday or Saturday. For that I really need to see a calendar not only to input a date, but to visualize the possible dates for my trip.
padjo
Input type date shows a calendar: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
lukan
Yes, but that is not what was recommended here above
"my best advice is to use the damn input type text"
dotancohen
No matter what placeholder text you put, you can not trust that 3-9-1980 is the same date for your user as it is for you.
mattmanser
This should be called bad advice about dates every developer should avoid.
ISO 8601 does NOT work with future dates. It does not work with cross border appointment booking.
ISO 8601 only works for dates and times that have already happened.
I have 20 years, have worked with apps that relied on future and past dates, have used date pickers since 2005 and would still hesitate to give advice about what is an incredibly complex problem that entirely depends on your use case.
burningChrome
15 years a front-end dev, 5 years as accessibility engineer.
Every time someone brings up a date picker I just wanna pull the pin on my parachute and jump out the window. 100% agree, its one of the hardest components to get right for so many different reasons. Like you mentioned in cross border booking, just in Canada they have three or four different ways to write a date. I worked for a healthcare company and just getting a consensus on that alone was a 8 month process of back and forth.
I feel your pain man, I really do.
Telaneo
> ISO 8601 does NOT work with future dates. It does not work with cross border appointment booking.
Why is this the case? Is it some time zone shenanigans?
rendaw
And what format does work for future dates?
Or do you mean that ISO 8601 doesn't work but RFC 3339 does work or some other updated ISO/RFC format?
mattmanser
Timezones change, more frequently than you realize. Some countries even used to change when summer time started regularly. It's got better than it used to be afaik.
Also you need to take into account where the user is going to be. With future dates, time is relative. So at the very least you often need the time + the timezone of the location.
Book me a table at 8, means book me a table in Berlin time at 8, not in San Francisco time at 8.
Same with displaying future dates, you need the context of where.
dotancohen
Tell us more. Please.
throwaway7783
Agreed. This works way better than struggling with date pickers not working on mobile, finding where the year picker is etc etc
slu
As a Dane, pikaday reads a little funny, because "pik" is a vulgar slang term for penis, equivalent to English words like dick or cock.
self_awareness
Is Pokemon popular in Denmark?
adornKey
Good, but not yet perfect. A lot of business is driven by week numbers. A perfect date picker should also display the week number somewhere.
JetSetIlly
In a business I used to work in even something as simple as week numbers caused problems. We had physical, cardboard desk calendars with the week numbers written on but even with that, there were some people who would use their own system.
For example: the calendars started the week on a Monday. However, if the first of the month was on a Sunday, when we came into work on the Monday, we were in 'week two' according to the calendar. For business purposes, there was no 'week one'.
My view was that we should just go by whatever was written on the calendar, but some people made up their own rules. Infuriating.
franga2000
This is cool, but the last two just awful. The most annoying part of typing in credit card info is getting into the flow of typing in numbers from a card, then having to switch to "number to month name, then scan a dropdown", then to "convert two to four digit year and scan another dropdown of seemingly random length", then back to typing numbers for the CVC. On a computer, you need to switch between keyboard and mouse and back, on mobile your keyboard open and closes, reflowing the whole window and moving elements around a handful of times.
In contrast to a "just type it" date picker (as in example 4) and staying in "just typing numbers" mode the whole time.
dairylee
I'm surprised the article doesn't talk about the <datalist> element. It makes the using the native time input much more user friendly as you can populate it with common times (e.g. Every 30 minutes: 09:00, 09:30, etc... instead of allowing every minute to be selected by default)
It's not quite fully supported in browsers but it's a nice enhancement to those where it works.
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
sureglymop
My take is that Date, Time and DateTime pickers are not enough. I want month pickers. Week pickers, custom interval pickers and then some. I really dislike how limited the selection of native form elements is.
recursive
Do you think there is anything missing from <input type="week"> or <input type="month"> other than Firefox support?
culi
Not just Firefox. Safari doesn't have it either. Not usable in a professional context.
I've been following the bugzilla issue for it for years now but there hasn't been any real progress on it. I don't think it'll happen until we can get it to an interop.[0] Speaking of which, interop 2026 is still taking suggestions[1] and I don't see any proposal for these inputs
[0] https://wpt.fyi/interop-2025
[1] https://github.com/web-platform-tests/interop/issues?q=is%3A...
bklyn11201
What is the simple explanation for the terrible support by Firefox and Safari? I figured this was relatively low-hanging fruit, widely used, a big boost for performance (date pickers often load 100s of locales and translations), and a giant move towards sanity for web app developers.
TZubiri
I want an AI that channels the force of Chronos the greek god of time
pimlottc
The context of the date being chosen should guide you to the appropriate picker.
For example, for a dinner reservation, a calendar can be useful to explore availability on weekends. But if I have to enter my birthdate, then it’s quicker to enter it numerically. I don’t need to consider other dates and the day of the week is irrelevant.
mnemonet
sevenseacat
I was going to say, I'm sure Pikaday was the name of a datepicker library I used many moons ago....
joelanman
For dates people know (say date of birth) just use text inputs
antman
All dates better have a paste capability, especially in gov sites where one might redo the submission multiple times
fluoridation
Part of the fun of being born on a leap day is finding software with incorrect date pickers/handling. I still come across it from time to time.
A few years ago I wrote a mobile app for use by patients of local doctors' surgeries. This meant a higher-than-average proportion of older, less tech-savvy users.
There was a flood of complaints about the OS-native date pickers, along the lines of: "There's no way to set the year! To get to my birth year, I had to tap the previous-month arrow 720 times!" (It seems people actually did this.)
This is what happens in the real world when Flat Design takes over UI controls. On both iOS and Android (a few years back, I don't know whether they've been improved now), the year just looked like a heading. Nothing whatsoever suggested it was a tappable UI element.
Now that mobile OS UI decisions are seemingly led entirely by aesthetics, instead of being run by a seasoned UX researcher like Don Norman, using an OS-native datepicker leaves the usability of our apps entirely at the mercy of what they choose to mess up next.
I used Pikaday on a few websites years ago. We're told these tools are now obsolete - I wish that were true.
(Changing the app to use textbox-dropdown-textbox for date-monthname-year - this is in the UK - stopped any further such complaints.)