9 ms·

Pikaday: A friendly guide to front-end date pickers

302 points by mnemonet 11mo ago

carlosjobim 11mo ago
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?
- AugurCognito 11mo ago
  https://github.com/Pikaday/Pikaday 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.
- nhumrich 11mo ago
  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
  - thoughtpalette 11mo ago
    This should be higher up. Posting a deprecated library with this title is an interesting choice.
    - phil-pickering 11mo ago
      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.
      - dbushell 11mo ago
        yep! I decided to repurpose the pikaday.com domain because it was still seeing a lot of traffic despite the project being unmaintained for years.
    - culi 11mo ago
      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!
      - foresterre 11mo ago
        I was quite confused too. I thought these were Pikaday implementations, partly because I usually use UK language in browsers, and then you get exclusively these (annoying to me) AM/PM date input pickers, and this time I didn't. I tried some of the inputs and found that they worked well for initial input, but editing inputs didn't (e.g. the masked date input cursor just jumps over previous decimals, when typing a new number) I made a reproduction video and tried to report it to the Pikaday issue tracker after which I found out it's deprecated. Going back, and comparing the readme with the page, does show that the post uses native inputs. ... I feel that could have been more explicit; in this post I expected Pikaday to have the option to use native pickers with some component styling.
- SoftTalker 11mo ago
  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.
  - carlosjobim 11mo ago
    The native date pickers are of low quality for usability. They have been so unpopular for so long, that you don't have any users who are accustomed to them. Because almost no apps or websites use the native date pickers. If you're fine with loosing most of your customers because they can't use your website, then go ahead with native date pickers. But I'm not going to ask my customers to scroll on a list of numbers on their iPhone or try to pinpoint a microscopic calendar on their computer to pick a date. User comes first. Developer comes last.
TheSisb2 11mo ago
Native datepickers fall apart when you need to handle different date formats as user preferences (not as browser default)
- 1718627440 11mo ago
  The browser, called the User Agent (UA), IS the program the user uses to interact with a website according to his preferences.
  - macintux 11mo ago
    Maybe. How many users change the defaults, or even know it’s an option?
    - 1718627440 11mo ago
      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.
  - sedatk 11mo ago
    That doesn't always work well in practice. I'm bilingual, and my preference is to use the locale closest to the language of the web site I'm visiting because it feels the most culturally coherent and the least surprising. I just can't reset my regional settings whenever I switch tabs.
    - 1718627440 11mo ago
      I also find this annoying, but this is due to websites ignoring the browser preferences. The browser supports specifying multiple languages and the website could select the one that the content is native in.
      - 11mo ago
kmoser 11mo ago
> 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.)
- cryptoz 11mo ago
  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 11mo ago
    This is actually how GTFS (a standard format for public transit data) works: https://gtfs.org/documentation/schedule/reference/#stop_timestxt 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 11mo ago
      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 11mo ago
    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.
pimlottc 11mo ago
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.
sureglymop 11mo ago
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 11mo ago
  Do you think there is anything missing from <input type="week"> or <input type="month"> other than Firefox support?
  - culi 11mo ago
    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 https://wpt.fyi/interop-2025 [1] https://github.com/web-platform-tests/interop/issues?q=is%3Aissue%20state%3Aopen%20label%3Afocus-area-proposal%20sort%3Areactions-%2B1-desc https://github.com/web-platform-tests/interop/issues?q=is%3A...
    - bklyn11201 11mo ago
      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.
      - culi 11mo ago
        It's simply not a priority. The Bugzilla has been open for 9 years. At one point the assignee of the bug simply stopped logging in and it took 7 months for the autonag to bother people. There simply aren't enough people asking for it. And the fact that it's a Chrome-exclusive feature means it's gonna take a backseat to features that Chrome AND Safari implement but are lacking in Firefox. There actually was some massive progress on it 3 months ago and it looks like they just need testing now but, again, it's just not a big priority > a big boost for performance (date pickers often load 100s of locales and translations) The native date/time pickers work great across all 3 major browsers in my experience. The use-cases for type="week" and type="month" are simply a lot less common.
Onavo 11mo ago
I wish there's a native calendly style time slot picker too.
vswaroop04 11mo ago
Does it have options like multiple date pickups, pickups for a particular month only, and a yearly pickup?
BhavdeepSethi 11mo ago
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.
- codegeek 11mo ago
  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.
mnemonet 11mo ago
Context: https://dbushell.com/2025/11/10/pikaday https://dbushell.com/2025/11/10/pikaday
- sevenseacat 11mo ago
  I was going to say, I'm sure Pikaday was the name of a datepicker library I used many moons ago....
tumidpandora 11mo ago
Great writeup, I think it'd be really helpful if this could be expanded to include handling timezones as well.
franga2000 11mo ago
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.
Muromec 11mo ago
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.
- throwaway7783 11mo ago
  Agreed. This works way better than struggling with date pickers not working on mobile, finding where the year picker is etc etc
- tshaddox 11mo ago
  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 11mo ago
    Input type date shows a calendar: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/date https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
    - lukan 11mo ago
      Yes, but that is not what was recommended here above "my best advice is to use the damn input type text"
- mattmanser 11mo ago
  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.
fluoridation 11mo ago
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.
recroad 11mo ago
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.
abanana 11mo ago
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.)
- bigfudge 11mo ago
  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 11mo ago
  Why were you using a calendar picker for a date of birth?
  - abanana 11mo ago
    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 11mo ago
      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.
frisbee6152 11mo ago
Just use a slider, duh
cies 11mo ago
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).
deleted 11mo ago
[deleted]
rkagerer 11mo ago
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.
- dotancohen 11mo ago
  What date is 3/9 in your date picker? I'm willing to bet it's not the date I'm thinking of. Everyone in my country uses the date format I just typed, to mean the date that I'm thinking of: Guveq bs Frcgrzore (rot13)
  - rkagerer 11mo ago
    User pretty quickly recognize the picker accepts day & month. The ordering is adaptable to locale, and context can be provided to the control as to whether to favor past/closest/future occurrences (eg. bookeeping arrears vs planning future calendar event). Year can always be included if the users wants to be unambiguous. I'm not familiar with the special 3/9 thing, but if you're serious that the behavior is something you think users in your locale would expect, then it wouldn't be hard to override the handler on a project using the picker and implement that.
    - sevenseacat 11mo ago
      meaning, is it September 3rd or March 9th (or something else entirely?)
      - dotancohen 11mo ago
        Exactly my point
    - watwut 11mo ago
      > The ordering is adaptable to locale This means that as a user, I have to toss a coin. The special 3/9 thing us that it can be either 9 March or 3 September. User locale is only loosely related to how user actually wants to have it or even assume to have it.
hollowturtle 11mo ago
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?
steveharrison 11mo ago
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.
- steveharrison 11mo ago
  I agree with the other things though like having multiple inputs for date ranges / trying to use native elements with just some custom styling.
slu 11mo ago
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 11mo ago
  Is Pokemon popular in Denmark?
self_awareness 11mo ago
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.
- pjerem 11mo ago
  I'm 100% with you except that modern native datepickers are awful. On iOS, selecting a date that is some years in the past or in the future is painful and entering the wrong date by mistake is really. But I agree that it doesn't mean that it's up to the application developers to fix this.
pflenker 11mo ago
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.
- carlosjobim 11mo ago
  > The best date picker is the one which doesn’t require picking a date How are we going to guess which date you want to take the train or flight?
  - pflenker 11mo ago
    Easy. You have data available which tells you about the most likely travel dates, and you set this as the default. Many booking platforms pick a weekend in 2 weeks or something like that. This predefined field changes the task from entering a date to correcting a date, where the prefilled date is likely close to the desired date and thus requires less input/changes than starting from scratch.
joelanman 11mo ago
For dates people know (say date of birth) just use text inputs https://design-system.service.gov.uk/components/date-input/ https://design-system.service.gov.uk/components/date-input/
- antman 11mo ago
  All dates better have a paste capability, especially in gov sites where one might redo the submission multiple times
dairylee 11mo ago
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/Elements/datalist#date_and_time_types https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
- carlosjobim 11mo ago
  > 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... This is a nightmare everywhere I have seen it implemented. I cannot think of any situation or use case where this is not the worst solution possible. In one system we use, you have to scroll through a 12000 pixel tall list of 15 minute increments. And you can't type to search, because they use AM/PM....
- jrochkind1 11mo ago
  It does talk about datalist! Near the end. Maybe they changed the article and added it after you commented? It doesn't say a ton about it. I'm interested in hearing more about usability of actual current browser implementations of these widgets, with dataalist but also in general.
andy_ppp 11mo ago
I wish this existed for a lot of UI elements and patterns, excellent work!
adornKey 11mo ago
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.
- deleted 11mo ago
  [deleted]
NoSalt 11mo ago
> "A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools." ~ Douglas Adams
mrinterweb 11mo ago
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???
edarchis 11mo ago
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.
- 0xis 10mo ago
  Last year I was working on a calendar supporting multiple calendar schemes. Currently it is only dogfooded with fictional calendars and a demo with heavy Vue and UI library. You inspired me to revive the project. Possibly remove the dependency and make it a usable datepicker. Lyowforall: https://github.com/0xis-cn/lyowforall https://github.com/0xis-cn/lyowforall

302 points by mnemonet 11mo ago

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?

AugurCognito 11mo ago
https://github.com/Pikaday/Pikaday 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.
nhumrich 11mo ago
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
- thoughtpalette 11mo ago
  This should be higher up. Posting a deprecated library with this title is an interesting choice.
  - phil-pickering 11mo ago
    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.
    - dbushell 11mo ago
      yep! I decided to repurpose the pikaday.com domain because it was still seeing a lot of traffic despite the project being unmaintained for years.
  - culi 11mo ago
    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!
    - foresterre 11mo ago
      I was quite confused too. I thought these were Pikaday implementations, partly because I usually use UK language in browsers, and then you get exclusively these (annoying to me) AM/PM date input pickers, and this time I didn't. I tried some of the inputs and found that they worked well for initial input, but editing inputs didn't (e.g. the masked date input cursor just jumps over previous decimals, when typing a new number) I made a reproduction video and tried to report it to the Pikaday issue tracker after which I found out it's deprecated. Going back, and comparing the readme with the page, does show that the post uses native inputs. ... I feel that could have been more explicit; in this post I expected Pikaday to have the option to use native pickers with some component styling.
SoftTalker 11mo ago
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.
- carlosjobim 11mo ago
  The native date pickers are of low quality for usability. They have been so unpopular for so long, that you don't have any users who are accustomed to them. Because almost no apps or websites use the native date pickers. If you're fine with loosing most of your customers because they can't use your website, then go ahead with native date pickers. But I'm not going to ask my customers to scroll on a list of numbers on their iPhone or try to pinpoint a microscopic calendar on their computer to pick a date. User comes first. Developer comes last.

TheSisb2 11mo ago

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

1718627440 11mo ago
The browser, called the User Agent (UA), IS the program the user uses to interact with a website according to his preferences.
- macintux 11mo ago
  Maybe. How many users change the defaults, or even know it’s an option?
  - 1718627440 11mo ago
    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.
- sedatk 11mo ago
  That doesn't always work well in practice. I'm bilingual, and my preference is to use the locale closest to the language of the web site I'm visiting because it feels the most culturally coherent and the least surprising. I just can't reset my regional settings whenever I switch tabs.
  - 1718627440 11mo ago
    I also find this annoying, but this is due to websites ignoring the browser preferences. The browser supports specifying multiple languages and the website could select the one that the content is native in.
    - 11mo ago

kmoser 11mo ago

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

cryptoz 11mo ago
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 11mo ago
  This is actually how GTFS (a standard format for public transit data) works: https://gtfs.org/documentation/schedule/reference/#stop_timestxt 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 11mo ago
    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 11mo ago
  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.

pimlottc 11mo ago

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.

sureglymop 11mo ago

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 11mo ago
Do you think there is anything missing from <input type="week"> or <input type="month"> other than Firefox support?
- culi 11mo ago
  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 https://wpt.fyi/interop-2025 [1] https://github.com/web-platform-tests/interop/issues?q=is%3Aissue%20state%3Aopen%20label%3Afocus-area-proposal%20sort%3Areactions-%2B1-desc https://github.com/web-platform-tests/interop/issues?q=is%3A...
  - bklyn11201 11mo ago
    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.
    - culi 11mo ago
      It's simply not a priority. The Bugzilla has been open for 9 years. At one point the assignee of the bug simply stopped logging in and it took 7 months for the autonag to bother people. There simply aren't enough people asking for it. And the fact that it's a Chrome-exclusive feature means it's gonna take a backseat to features that Chrome AND Safari implement but are lacking in Firefox. There actually was some massive progress on it 3 months ago and it looks like they just need testing now but, again, it's just not a big priority > a big boost for performance (date pickers often load 100s of locales and translations) The native date/time pickers work great across all 3 major browsers in my experience. The use-cases for type="week" and type="month" are simply a lot less common.

Onavo 11mo ago

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

vswaroop04 11mo ago

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

BhavdeepSethi 11mo ago

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.

codegeek 11mo ago
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.

mnemonet 11mo ago

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

sevenseacat 11mo ago
I was going to say, I'm sure Pikaday was the name of a datepicker library I used many moons ago....

tumidpandora 11mo ago

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

franga2000 11mo ago

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.

Muromec 11mo ago

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.

throwaway7783 11mo ago
Agreed. This works way better than struggling with date pickers not working on mobile, finding where the year picker is etc etc
tshaddox 11mo ago
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 11mo ago
  Input type date shows a calendar: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/date https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
  - lukan 11mo ago
    Yes, but that is not what was recommended here above "my best advice is to use the damn input type text"
mattmanser 11mo ago
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.

fluoridation 11mo ago

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.

recroad 11mo ago

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.

abanana 11mo ago

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

bigfudge 11mo ago
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 11mo ago
Why were you using a calendar picker for a date of birth?
- abanana 11mo ago
  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 11mo ago
    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.

frisbee6152 11mo ago

Just use a slider, duh

cies 11mo ago

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

deleted 11mo ago

[deleted]

rkagerer 11mo ago

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.

dotancohen 11mo ago
What date is 3/9 in your date picker? I'm willing to bet it's not the date I'm thinking of. Everyone in my country uses the date format I just typed, to mean the date that I'm thinking of: Guveq bs Frcgrzore (rot13)
- rkagerer 11mo ago
  User pretty quickly recognize the picker accepts day & month. The ordering is adaptable to locale, and context can be provided to the control as to whether to favor past/closest/future occurrences (eg. bookeeping arrears vs planning future calendar event). Year can always be included if the users wants to be unambiguous. I'm not familiar with the special 3/9 thing, but if you're serious that the behavior is something you think users in your locale would expect, then it wouldn't be hard to override the handler on a project using the picker and implement that.
  - sevenseacat 11mo ago
    meaning, is it September 3rd or March 9th (or something else entirely?)
    - dotancohen 11mo ago
      Exactly my point
  - watwut 11mo ago
    > The ordering is adaptable to locale This means that as a user, I have to toss a coin. The special 3/9 thing us that it can be either 9 March or 3 September. User locale is only loosely related to how user actually wants to have it or even assume to have it.

hollowturtle 11mo ago

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?

steveharrison 11mo ago

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.

steveharrison 11mo ago
I agree with the other things though like having multiple inputs for date ranges / trying to use native elements with just some custom styling.

slu 11mo ago

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 11mo ago
Is Pokemon popular in Denmark?

self_awareness 11mo ago

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.

pjerem 11mo ago
I'm 100% with you except that modern native datepickers are awful. On iOS, selecting a date that is some years in the past or in the future is painful and entering the wrong date by mistake is really. But I agree that it doesn't mean that it's up to the application developers to fix this.

pflenker 11mo ago

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.

carlosjobim 11mo ago
> The best date picker is the one which doesn’t require picking a date How are we going to guess which date you want to take the train or flight?
- pflenker 11mo ago
  Easy. You have data available which tells you about the most likely travel dates, and you set this as the default. Many booking platforms pick a weekend in 2 weeks or something like that. This predefined field changes the task from entering a date to correcting a date, where the prefilled date is likely close to the desired date and thus requires less input/changes than starting from scratch.

joelanman 11mo ago

For dates people know (say date of birth) just use text inputs https://design-system.service.gov.uk/components/date-input/ https://design-system.service.gov.uk/components/date-input/

antman 11mo ago
All dates better have a paste capability, especially in gov sites where one might redo the submission multiple times

dairylee 11mo ago

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/Elements/datalist#date_and_time_types https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

carlosjobim 11mo ago
> 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... This is a nightmare everywhere I have seen it implemented. I cannot think of any situation or use case where this is not the worst solution possible. In one system we use, you have to scroll through a 12000 pixel tall list of 15 minute increments. And you can't type to search, because they use AM/PM....
jrochkind1 11mo ago
It does talk about datalist! Near the end. Maybe they changed the article and added it after you commented? It doesn't say a ton about it. I'm interested in hearing more about usability of actual current browser implementations of these widgets, with dataalist but also in general.

andy_ppp 11mo ago

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

adornKey 11mo ago

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.

deleted 11mo ago
[deleted]

NoSalt 11mo ago

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

mrinterweb 11mo ago

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???

edarchis 11mo ago

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.

0xis 10mo ago
Last year I was working on a calendar supporting multiple calendar schemes. Currently it is only dogfooded with fictional calendars and a demo with heavy Vue and UI library. You inspired me to revive the project. Possibly remove the dependency and make it a usable datepicker. Lyowforall: https://github.com/0xis-cn/lyowforall https://github.com/0xis-cn/lyowforall