Pikaday: A friendly guide to front-end date pickers (opens in new tab)

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.)

> 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.)

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.

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.

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.

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.

Context: https://dbushell.com/2025/11/10/pikaday

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.

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.

What if the daylight saving's "extra hour" (that occurs in most of Europe between 02:00 and 03:00 (that is AM) in the night from Saturday to Sunday is important to the business you are making an application for?

How to make sure users can pick either a time in the first 02:00 to 03:00 or in the second? I know I can express it in offset datetimes: but how to show this to he user?

Do native datetime pickers allow this? I'm afraid not.

So I have (had) to roll my own :)

Also: native date pickers use the format of the browser, which may not be what the rest of the application was setup to. I takes away the "locale setting" from the app, to hands it over to the browser.

I like my browser in en_US, unless when dealing with date (I prefer yyyy-mm-dd like most programmers), size measurements (metric) and paper sized (I prefer A4).

It's funny to talk about internationalization but only support Western date format.

If you are managing hospital admissions in Nepal, you have to be able to provide the date in Nepalese calendar and in the common one. And believe me, the Nepalese calendar is a complex one.

In Ethiopia, you'll have to support 13 months but they'll be close enough to common dates that people will manage mentally. But imagine that you have to handle a quarter of 4 months, one of which is 5 or 6 days long.

If someone has a good reference for a properly international picker, I'm all ears.

All those date pickers that don't give you the ability to type a date in as plain text just plain suck.

Airline websites are particularly awful for this.

I made a C# datepicker a long time ago that allows both textual and gui input. Anything parseable as a date is accepted in the text field - it even recognizes partial strings like "3/23" for March 23.

I used to create software for rapid data entry, so I know a thing or two about efficient UI. Maybe I should open-source it.

From what I've learned, be as explicit as possible when users enter dates.

We had to change our date of birth field in the user sign-up to three separate "Month Name","Day" and "Year" drop downs, since so many people made mistakes (fat finger/ swap month and day) from the "MM/DD/YYYY" field, and would then send support ticket to update it.

For dates people know (say date of birth) just use text inputs

https://design-system.service.gov.uk/components/date-input/

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/...

I think this article misses the fact that the native date and time pickers look ugly in Chrome, and that a lot of websites are ultimately an extension of a brand, not just a tool where function > form. The Airbnb date range picker looking on-brand makes the experience seem a lot more slick. There are more things to optimise for than just accessibility.

It is refreshing to see a date picker that the user knows how to enter date with their keyboard. Defaulting to custom UI for date/time pickers is so bizarre. My favorite (/s) is when you're using an android and you get the web mocked version of an iOS time picker where you have to rotate wheels???

The best date picker is the one which doesn’t require picking a date. If done correctly, the browser can auto-fill your birthday, for example. In many other cases it’s possible and makes sense to guess a date and prefill the date field. Phones attempt the same with being biased towards entering the current date or datetime.

Web devs should really discover that using standard native controls is the way to go.

The worst thing that can happen to a website is to use a custom scrolling logic/scrollbar. It never behaves correctly.

Next step would be discovering that we have been doing this since Windows 3.11, and we lost this ability because of web programmers.

The main practical problem here is that the "step" attribute is not widely supported so if you want the user to pick times in 30 minute increments, it won't work.

> "A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools."

~ Douglas Adams

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.

Native datepickers fall apart when you need to handle different date formats as user preferences (not as browser default)

Great writeup, I think it'd be really helpful if this could be expanded to include handling timezones as well.

Does it have options like multiple date pickups, pickups for a particular month only, and a yearly pickup?

Except native date pickers still sucks on desktop, i really dislike the chrome version on macos and can't say nice things to the firefox one. Also browsers behave differently when trying to validate the date entered in the input, if you listen for on change event, chrome fires it as soon as a valid year is entered except if want to type 2025 starting with the 2 would result in 0002 on the input and... that's a valid year, what you do validate or not? wait for blur event to check the final entered date?

I wish this existed for a lot of UI elements and patterns, excellent work!

I wish there's a native calendly style time slot picker too.

They are wrong. Most OS native date pickers are very bad from a usability perspective. A javascript date picker fixes these issues, and allows more functions.

And why are they arguing against their own product? Even making up bogus claims that using js date pickers would be illegal in Europe?

Just use a slider, duh