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.)
They don't appear to have tested a dropdown for the month name, with text boxes for date and year. I've read elsewhere in UX research that the month name should be preferred, for clarity, over entering another number. So it's unfortunate that that page's research isn't complete ("we will continue our testing") and doesn't appear to have ever been followed up.
(I worked on this pattern) Our guidance is to accept both names and numbers in the back end so people can enter either. In our testing, text inputs (with a numeric keyboard on mobile) is better than selects. Some people struggle with using selects, we don't see those issues in text inputs. That guidance maybe be about people not knowing the order of the inputs (DD MM YY, MM DD YY) but our pattern is clearly labeled for each input so we don't get that issue.
We did continue our testing which resulted in the pattern in the design system which is linked.
I'm not sure of every type of trouble folks might have using selects, but for the subset where using a hardware keyboard is required, you can usually type into a focused select just as you can type into a text input. Getting an Android/iOS on-screen keyboard to do this without a special configuration might not be a thing, I'll admit.
The only tricky part, for me, is deciding whether I should type a state abbreviation or a few letters of the full state name, which in my case differ enough to be quite annoying.
They did some research elsewhere on dropdowns and found a lot of users do not realise they can scroll through the list and would get confused, might be why they ruled out dropdowns entirely for date pickers.
I'm always confused by the anglocentrism of these kinds of ux "standards" because for example in mandarin we call days (三號）, weekdays （星期二 / 禮拜二）, months （二十月）, and years by numbers... And in Japanese they have similar I believe but also have non numbers for weekdays. I imagine other languages have similar flukes, wouldn't be surprised if there was one out there that had special words for the first couple days of the month or something.
> Ultimately they found the best experience was three text boxes, day, month and year
This is what we found was most acceptable for our banking users. They were coming from terminal interfaces. This is a UI/UX flow that we just had to go with. We experimented with fancy date pickers (i.e., <input type='date'>) and it lasted about a month before we were forced to refactor. We kept a date picker icon (exempt from tab order) for novice / younger employees who prefer the tap-tap-tap bs.
If you are replacing a mainframe app with something on the web, the least you can do is make a half-ass attempt to keep the # of physical fields the same and place them in the same tab order. This can make or break your pitch in a competitive B2B SaaS environment. We sold to the users, not to the business. The users then sold to the business for us. You cannot get end users to help sell for you if they don't like the UX. They know they'll have to live with it every day if they successfully advocate for it.
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.
I get a real sense from some UX designers that following what he says is uncool. The vibe I get is one of how some people don't want to follow older people, with that 'we will do what we think best' sort of attitude. As thought UX is based on fashion not on concrete principles.
I've seen a few youngish graphic designers calling themselves "UX designers" even though they have zero learning, experience, or apparently knowledge in UX. They're just copying fashions they think are "cool" while genuinely thinking they're doing something clever. They gave me the impression that they simply don't know UX is a discipline of its own with a long history of actual user-centric research.
It's a form of arrogance, determined they know best. On the rare occasions that they get to the feedback stage (rather than just rushing on to the next project), they've acted stunned when they realised that people have difficulty using something they designed, and they were absolutely determined that the user in question must be incredibly stupid. Thoughts of the usability of what they've built don't even enter their mind.
I'd like to hope these people are in the minority, but when I see poor user interfaces in so many different places, I'm not so sure.
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.
Even if, that does not help. When asked for a birthday I need validation of the date in country when I was born, not the country I'm in, not the locale I'm using for display and not the locale server/requesting company is in.
Obviously, but additionally, providing validation on the frontend can help UX a lot.
Doing that can provide much quicker feedback compared to an error thrown at the user only after submitting a form, which can get especially annoying if the latter loses (some of) its values due to submission.
And one solution for that problem can be using a native picker.
I do understand what "client-side" validation is, but I wish it had a different name, because people think they can just validate client-side and they do not bother doing it on the server... for some reason, I do not know. It should be obvious though, right? Yet it is not.
I think your point is just emphasizing how bad these native datepickers are. They are specifically used by the browsers for <input type="date">. Their purpose is to enter a date. That's why their use in this way is absolutely standard (far more so than the term "calendar picker" as far as I'm aware. The user's not choosing a calendar, they're choosing a date). That doesn't mean the choice of input method can't be improved, but highlighting it as a pet peeve won't make it happen at scale. What do you suggest instead?
The answer shouldn't be "create something custom for entering dates that don't happen to be in the current year", it should be "fix the datepicker so it's fit for purpose".
I am so glad that so many people in this thread confirm how bad the native date pickers are; i thought I was alone.
Just picking the year is so difficult already on both Android and iOS as well as desktop Chrome, so a custom widget is immediately 100x better.
Yes, in theory it would be best to display the native picker because in theory it has a great UX, but in practice the native browsers' implementations are mostly just really, really bad, for whatever reason.
That's what I really dislike about the linked article - it doesn't even check the native implementations for their quality but just argues as if they are great.
Ideally there would be an input type for this, month comes close to the correct UI on iOS but has lots of problems. I don’t think the calendar picker style will ever work well for entering birthdays and such, so yeah the answer is build your own thing or use a library.
> 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).
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
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.
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).
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.
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.
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.
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.
If I want to book an appointment for April 12th 2027 at 2:00pm, then that's the time I want.
If my locale decides in 2026 to opt out of daylight savings time and not use it anymore -- it does not mean my appointment is now at 1:00pm instead. My appointment is still at April 12th 2027 at 2:00pm. But if I had saved it as a prediction of a UTC time in ISO 8601, then the system would think my appointment was now at 1:00pm.
This is why it has to do with dates being in the future. A past date-time can be converted to a UTC time represneted in ISO8601 that will not ever change (if it was converted properly).
I'm not sure where you got restaurants from -- you are the first person in this thread to mention restaurants? That is one use case for storing dates and times in the future, but certainly not the only one! There are of course some where the time zone is not "obvious". You realize there is software that's used for things other than restaurant orders and reservations, right? (Also I can imagine a restaurant that's a mobile food truck in an area near a timezone border...)
You speak very authoritatively and combatively about something I think you may not be on the same page about.
You can represent time zones with that format. So long as you have a source time zone, target time zone and tzdata you can convert any time accounting for all the particularities of any particular zone.
ISO 8601 timezone only allows an offset. You can't encode "04:00 in Cairo on 13th November 2036" as there's no way to know what UTC offset Cairo will have in October 31st 2036.
> 2036-11-13 04:00:00 Africa/Cairo
Is fine
> 2036-11-13 04:00:00 +0200
Is not, as the rules around moving from +3 to +2 may well have changed by them.
That’s got literally nothing to do with ISO 8601 though. Times are just hard and there’s no way to know the future with any kind of certainty. In this case there’s no way of knowing whether Egypt will by 2036 have changed their timezone or added or eliminated DST. Nothing to do with ISO 8601, just the world is uncertain.
Take the UK for another example. The daylight savings dates are actually set by act of parliament. Although they always have fallen in the pattern that everyone knows, for dates in future years beyond the ones they have already set, they could hypothetically (if you want to be literal-minded about it) change the law to make DST happen on absolutely any day of the year or not at all.
ISO 8601 only allows timezones as offsets, not as locations.
If it allowed "Africa/Cairo" instead of "+0200" that would be fine.
> they could hypothetically (if you want to be literal-minded about it) change the law to make DST happen on absolutely any day of the year or not at all.
That's the whole point - that's why you store future date/times with the location, not the offset, and not in UTC
The fact that ISO8601 does not store time zones (only fixed UTC offsets, which is not the same thing) obviously has something to do with ISO8601. I'm not sure what you're going on about?
Are you scheduling a restaurant reservation for 2036? Will it change from 09 to 10 in the morning depending on DST?
Sure, we cant know what unix date it resolves to, but it doesn't matter, because future dates are more of a contract intentionally bound to context that is subject to change.
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.
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.
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.
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.
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).
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.
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.
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.
I should have clarified, by adaptable to locale I meant you have control via configuration.
The developer can supply a default or even lock it down. E.g. Users of the last app I built incorporating it always expected M/D and the app operated on a kiosk, so that's how we did it.
If no initial configuration is provided, the default does feed from the date format set up in the system locale settings. I agree in practice that's not always guaranteed to reflect what the user wants, but it is the intended spot the OS provides for configuring this and is usually the best source for a default: https://i.imgur.com/KShFPtb.png
If the developer hasn't locked it down, it's easy for a user to override (either via a setting exposed in the app - which you could even attach to a toggle right in the input field's context menu if you'd like, or via a config file / registry setting).
I missed the rot13 thing, and thought "Guveq bs Frcgrzore" referred to some kind of unique cultural event where dotancohen came from (like if I referred to 9/11 in the USA, or typed in "Thanksgiving").
Finally, you could also just type "Mar 9" for a one-off - or use the dropped-down GUI instead of typing anything in the box at all, if keying is not for you.
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.
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.
> 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....
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.
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???
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.
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.
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.
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.
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.
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.
You set all the language you want with priorities and the webserver knows it's own language and serves you the intersection with the highest priority. Or do I misunderstand your question?
I mean the locale, not the language. Many web sites are in a single language and target a specific culture. I want that to be respected by the browser for input type=date and other similar elements based on web site’s language, not the other way around. That’s my preference.
Okay, I already have preferred languages selected: English and Turkish. If I visit a `<html lang="tr">` page I should see date inputs rendered in Turkish culture right? That's not the case unfortunately.
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.
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?
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.
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.
> 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
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.
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.)
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/
They don't appear to have tested a dropdown for the month name, with text boxes for date and year. I've read elsewhere in UX research that the month name should be preferred, for clarity, over entering another number. So it's unfortunate that that page's research isn't complete ("we will continue our testing") and doesn't appear to have ever been followed up.
(I worked on this pattern) Our guidance is to accept both names and numbers in the back end so people can enter either. In our testing, text inputs (with a numeric keyboard on mobile) is better than selects. Some people struggle with using selects, we don't see those issues in text inputs. That guidance maybe be about people not knowing the order of the inputs (DD MM YY, MM DD YY) but our pattern is clearly labeled for each input so we don't get that issue.
We did continue our testing which resulted in the pattern in the design system which is linked.
I'm not sure of every type of trouble folks might have using selects, but for the subset where using a hardware keyboard is required, you can usually type into a focused select just as you can type into a text input. Getting an Android/iOS on-screen keyboard to do this without a special configuration might not be a thing, I'll admit.
The only tricky part, for me, is deciding whether I should type a state abbreviation or a few letters of the full state name, which in my case differ enough to be quite annoying.
They did some research elsewhere on dropdowns and found a lot of users do not realise they can scroll through the list and would get confused, might be why they ruled out dropdowns entirely for date pickers.
I'm always confused by the anglocentrism of these kinds of ux "standards" because for example in mandarin we call days (三號）, weekdays （星期二 / 禮拜二）, months （二十月）, and years by numbers... And in Japanese they have similar I believe but also have non numbers for weekdays. I imagine other languages have similar flukes, wouldn't be surprised if there was one out there that had special words for the first couple days of the month or something.
> Ultimately they found the best experience was three text boxes, day, month and year
This is what we found was most acceptable for our banking users. They were coming from terminal interfaces. This is a UI/UX flow that we just had to go with. We experimented with fancy date pickers (i.e., <input type='date'>) and it lasted about a month before we were forced to refactor. We kept a date picker icon (exempt from tab order) for novice / younger employees who prefer the tap-tap-tap bs.
If you are replacing a mainframe app with something on the web, the least you can do is make a half-ass attempt to keep the # of physical fields the same and place them in the same tab order. This can make or break your pitch in a competitive B2B SaaS environment. We sold to the users, not to the business. The users then sold to the business for us. You cannot get end users to help sell for you if they don't like the UX. They know they'll have to live with it every day if they successfully advocate for it.
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.
> a seasoned UX researcher like Don Norman
I get a real sense from some UX designers that following what he says is uncool. The vibe I get is one of how some people don't want to follow older people, with that 'we will do what we think best' sort of attitude. As thought UX is based on fashion not on concrete principles.
Yes, I totally agree.
I've seen a few youngish graphic designers calling themselves "UX designers" even though they have zero learning, experience, or apparently knowledge in UX. They're just copying fashions they think are "cool" while genuinely thinking they're doing something clever. They gave me the impression that they simply don't know UX is a discipline of its own with a long history of actual user-centric research.
It's a form of arrogance, determined they know best. On the rare occasions that they get to the feedback stage (rather than just rushing on to the next project), they've acted stunned when they realised that people have difficulty using something they designed, and they were absolutely determined that the user in question must be incredibly stupid. Thoughts of the usability of what they've built don't even enter their mind.
I'd like to hope these people are in the minority, but when I see poor user interfaces in so many different places, I'm not so sure.
> the year just looked like a heading. Nothing whatsoever suggested it was a tappable UI element.
IT IS TAPPABLE???
I feel like I have had trouble figuring out how to jump years in those too!
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">.
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.
Doesn't the browser automatically a handle locales when using the HTML5 input=date?
Even if, that does not help. When asked for a birthday I need validation of the date in country when I was born, not the country I'm in, not the locale I'm using for display and not the locale server/requesting company is in.
I am thinking about locale of how a date/time is formatted for display/input. Including language-specific month names etc.
Date picker widgets do not solve any validation problem, because validation happens on the server side and client input is not to be trusted.
Obviously, but additionally, providing validation on the frontend can help UX a lot. Doing that can provide much quicker feedback compared to an error thrown at the user only after submitting a form, which can get especially annoying if the latter loses (some of) its values due to submission. And one solution for that problem can be using a native picker.
That is called input assistance, confusing it with validation is the source of millions of security problems.
That’s an interesting suggestion, but it is not, it’s called (client side) form validation
https://html.spec.whatwg.org/multipage/forms.html#client-sid...
I definitely see your reasoning for wishing it had a different name though.
I do understand what "client-side" validation is, but I wish it had a different name, because people think they can just validate client-side and they do not bother doing it on the server... for some reason, I do not know. It should be obvious though, right? Yet it is not.
No, it's not. And if that's what confuses one, it will not be the actual source of these problems.
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.
I think your point is just emphasizing how bad these native datepickers are. They are specifically used by the browsers for <input type="date">. Their purpose is to enter a date. That's why their use in this way is absolutely standard (far more so than the term "calendar picker" as far as I'm aware. The user's not choosing a calendar, they're choosing a date). That doesn't mean the choice of input method can't be improved, but highlighting it as a pet peeve won't make it happen at scale. What do you suggest instead?
The answer shouldn't be "create something custom for entering dates that don't happen to be in the current year", it should be "fix the datepicker so it's fit for purpose".
I am so glad that so many people in this thread confirm how bad the native date pickers are; i thought I was alone.
Just picking the year is so difficult already on both Android and iOS as well as desktop Chrome, so a custom widget is immediately 100x better.
Yes, in theory it would be best to display the native picker because in theory it has a great UX, but in practice the native browsers' implementations are mostly just really, really bad, for whatever reason.
That's what I really dislike about the linked article - it doesn't even check the native implementations for their quality but just argues as if they are great.
Ideally there would be an input type for this, month comes close to the correct UI on iOS but has lots of problems. I don’t think the calendar picker style will ever work well for entering birthdays and such, so yeah the answer is build your own thing or use a library.
> 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.
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).
And even if they have, representations of noon and midnight differ.
Maybe at that point they should say "Closed 1am to 8am" instead.
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
I work with a factory that uses 32 hour timestamps, as some employees work a night shift.
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.
> 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).
and yet google calendar by default translates them into the current (GPS-based) timezone ....
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"
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.
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.
> 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?
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.
This has nothing to with the dates being in the future and only with convention and labeling the field correctly.
And in the table example you don't need the "where", because it's obviously in the restaurant's timezone.
If I want to book an appointment for April 12th 2027 at 2:00pm, then that's the time I want.
If my locale decides in 2026 to opt out of daylight savings time and not use it anymore -- it does not mean my appointment is now at 1:00pm instead. My appointment is still at April 12th 2027 at 2:00pm. But if I had saved it as a prediction of a UTC time in ISO 8601, then the system would think my appointment was now at 1:00pm.
This is why it has to do with dates being in the future. A past date-time can be converted to a UTC time represneted in ISO8601 that will not ever change (if it was converted properly).
I'm not sure where you got restaurants from -- you are the first person in this thread to mention restaurants? That is one use case for storing dates and times in the future, but certainly not the only one! There are of course some where the time zone is not "obvious". You realize there is software that's used for things other than restaurant orders and reservations, right? (Also I can imagine a restaurant that's a mobile food truck in an area near a timezone border...)
You speak very authoritatively and combatively about something I think you may not be on the same page about.
This is nothing to do with ISO 8601 though.
You can represent time zones with that format. So long as you have a source time zone, target time zone and tzdata you can convert any time accounting for all the particularities of any particular zone.
ISO 8601 timezone only allows an offset. You can't encode "04:00 in Cairo on 13th November 2036" as there's no way to know what UTC offset Cairo will have in October 31st 2036.
> 2036-11-13 04:00:00 Africa/Cairo
Is fine
> 2036-11-13 04:00:00 +0200
Is not, as the rules around moving from +3 to +2 may well have changed by them.
That’s got literally nothing to do with ISO 8601 though. Times are just hard and there’s no way to know the future with any kind of certainty. In this case there’s no way of knowing whether Egypt will by 2036 have changed their timezone or added or eliminated DST. Nothing to do with ISO 8601, just the world is uncertain.
Take the UK for another example. The daylight savings dates are actually set by act of parliament. Although they always have fallen in the pattern that everyone knows, for dates in future years beyond the ones they have already set, they could hypothetically (if you want to be literal-minded about it) change the law to make DST happen on absolutely any day of the year or not at all.
ISO 8601 only allows timezones as offsets, not as locations.
If it allowed "Africa/Cairo" instead of "+0200" that would be fine.
> they could hypothetically (if you want to be literal-minded about it) change the law to make DST happen on absolutely any day of the year or not at all.
That's the whole point - that's why you store future date/times with the location, not the offset, and not in UTC
There's an extension to ISO8601 that fixes this and is starting to become supported in libraries:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...The fact that ISO8601 does not store time zones (only fixed UTC offsets, which is not the same thing) obviously has something to do with ISO8601. I'm not sure what you're going on about?
Are you scheduling a restaurant reservation for 2036? Will it change from 09 to 10 in the morning depending on DST?
Sure, we cant know what unix date it resolves to, but it doesn't matter, because future dates are more of a contract intentionally bound to context that is subject to change.
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?
Tell us more. Please.
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.
Which is why locale settings exist and are important to get right before asking for user input
it's obviously the 3rd of september 1980, but without the 0-padding it looks icky.
Agreed. This works way better than struggling with date pickers not working on mobile, finding where the year picker is etc etc
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.
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.
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.
I want an AI that channels the force of Chronos the greek god of time
Context: https://dbushell.com/2025/11/10/pikaday
I was going to say, I'm sure Pikaday was the name of a datepicker library I used many moons 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.
Is Pokemon popular in Denmark?
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.
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.
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).
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.
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)
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.
> 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.
I should have clarified, by adaptable to locale I meant you have control via configuration.
The developer can supply a default or even lock it down. E.g. Users of the last app I built incorporating it always expected M/D and the app operated on a kiosk, so that's how we did it.
If no initial configuration is provided, the default does feed from the date format set up in the system locale settings. I agree in practice that's not always guaranteed to reflect what the user wants, but it is the intended spot the OS provides for configuring this and is usually the best source for a default: https://i.imgur.com/KShFPtb.png
If the developer hasn't locked it down, it's easy for a user to override (either via a setting exposed in the app - which you could even attach to a toggle right in the input field's context menu if you'd like, or via a config file / registry setting).
I missed the rot13 thing, and thought "Guveq bs Frcgrzore" referred to some kind of unique cultural event where dotancohen came from (like if I referred to 9/11 in the USA, or typed in "Thanksgiving").
Finally, you could also just type "Mar 9" for a one-off - or use the dropped-down GUI instead of typing anything in the box at all, if keying is not for you.
meaning, is it September 3rd or March 9th (or something else entirely?)
Exactly my point
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.
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/...
> 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....
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.
For dates people know (say date of birth) just use text inputs
https://design-system.service.gov.uk/components/date-input/
All dates better have a paste capability, especially in gov sites where one might redo the submission multiple times
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???
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.
I agree with the other things though like having multiple inputs for date ranges / trying to use native elements with just some custom styling.
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.
> 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?
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.
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.
> "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.
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.
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.
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.
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.
I don’t think there’s a browser setting that lets you use the locale the web site’s language in, is there?
You set all the language you want with priorities and the webserver knows it's own language and serves you the intersection with the highest priority. Or do I misunderstand your question?
I mean the locale, not the language. Many web sites are in a single language and target a specific culture. I want that to be respected by the browser for input type=date and other similar elements based on web site’s language, not the other way around. That’s my preference.
What your browser calls a language, is in fact a locale. You specify en_US, not English.
That would be equivalent to no setting a preferred locale or adding all the available locales.
Okay, I already have preferred languages selected: English and Turkish. If I visit a `<html lang="tr">` page I should see date inputs rendered in Turkish culture right? That's not the case unfortunately.
See it for yourself:
lang=en-US -> https://kod.ssg.dev/localetest/
lang=tr-TR -> https://kod.ssg.dev/localetest/index-tr.html
How do you configure Firefox to show date-time picker in 24h format?
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.
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?
I wish this existed for a lot of UI elements and patterns, excellent work!
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 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.
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.
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.
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.
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!
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.
Just use a slider, duh