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.
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.
> 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.)
> 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.
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).
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.
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.
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.
In the case of Japanese, there is 午前・午後 for 12-hour time. e.g. 午後９時に着く (arrive at 9 P.M.). If it's obvious from context, then only the hour is said. e.g. in「明日３時にね」, the flow of the conversation disambiguates the hour (it's also unlikely the speaker means 3 A.M.)
There are also other ways to convey 12-hour time. e.g. 朝６時に起きる (wake up at 6 A.M. / wake up at 6 in the morning).
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).
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-month-year - this is in the UK - stopped any further such complaints.)
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.
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.
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
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.
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.
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.
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 specific dates, I prefer 3 dropdowns with explicit strings for months. So the dropdowns would be "7", "January","2026" etc instead of 01/07/2026 or 07/01/2026 ensuring there is no confusion.
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.
When all websites respect their settings and they don't like what the websites do, they will search "how do I change X...", which would point them to the browser settings. If no website respect them, they won't bother. Also these settings come from the OS, which asked the user on install what e.g. date format he wants to use.
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?
> We’ve decided to archive the Pikaday repository on GitHub. The project has not been actively maintained for years.
> Pikaday was started before <input type="date"> was supported in browsers and before custom elements and component frameworks. Pikaday is probably not the right choice today.
> Pikaday was started before <input type="date"> was supported in browsers and before custom elements and component frameworks. Pikaday is probably not the right choice today
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.
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.
Input type date shows a calendar: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
Yes, but that is not what was recommended here above
"my best advice is to use the damn input type text"
Agreed. This works way better than struggling with date pickers not working on mobile, finding where the year picker is etc etc
> 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.)
> 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.
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).
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
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.
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.
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.
Maybe at that point they should say "Closed 1am to 8am" instead.
I think it is more common for them to write 8:00 to 25:00 - omitting AM and PM.
AM and PM is used in a few languages (mostly English) but many don't have it in their vocabulary at all, which probably includes Japanese.
In the case of Japanese, there is 午前・午後 for 12-hour time. e.g. 午後９時に着く (arrive at 9 P.M.). If it's obvious from context, then only the hour is said. e.g. in「明日３時にね」, the flow of the conversation disambiguates the hour (it's also unlikely the speaker means 3 A.M.)
There are also other ways to convey 12-hour time. e.g. 朝６時に起きる (wake up at 6 A.M. / wake up at 6 in the morning).
> 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".
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).
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-month-year - this is in the UK - stopped any further such complaints.)
Why were you using a calendar picker for a date of birth?
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">.
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.
Context: https://dbushell.com/2025/11/10/pikaday
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.
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.
Do you think there is anything missing from <input type="week"> or <input type="month"> other than Firefox support?
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...
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.
I want an AI that channels the force of Chronos the greek god of time
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.
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.
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 specific dates, I prefer 3 dropdowns with explicit strings for months. So the dropdowns would be "7", "January","2026" etc instead of 01/07/2026 or 07/01/2026 ensuring there is no confusion.
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.
Just use a slider, duh
Great writeup, I think it'd be really helpful if this could be expanded to include handling timezones as well.
Native datepickers fall apart when you need to handle different date formats as user preferences (not as browser default)
The browser, called the User Agent (UA), IS the program the user uses to interact with a website according to his preferences.
Maybe. How many users change the defaults, or even know it’s an option?
When all websites respect their settings and they don't like what the websites do, they will search "how do I change X...", which would point them to the browser settings. If no website respect them, they won't bother. Also these settings come from the OS, which asked the user on install what e.g. date format he wants to use.
Does it have options like multiple date pickups, pickups for a particular month only, and a yearly pickup?
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?
https://github.com/Pikaday/Pikaday
> We’ve decided to archive the Pikaday repository on GitHub. The project has not been actively maintained for years.
> Pikaday was started before <input type="date"> was supported in browsers and before custom elements and component frameworks. Pikaday is probably not the right choice today.
You know what's bad? A bespoke date picker that behaves differently from how the date picker works on the rest of the apps on the device.
Usability doesn't matter when there's an established behavior. Users get used to how it works, and then differences cause stumbling blocks.
Use the native date pickers.
From the GitHub project:
> Pikaday was started before <input type="date"> was supported in browsers and before custom elements and component frameworks. Pikaday is probably not the right choice today
The project itself has been deprecated
This should be higher up. Posting a deprecated library with this title is an interesting choice.
You're all getting a little confused!
This is an up-to-date guide demonstrating why the old deprecated Pikaday JavaScript Datepicker is no longer needed.
Did you click on the OP? This whole post is about using native date pickers. The very first words are:
> Who needs a JavaScript date picker?
> The answer, in most cases, is nobody!