Pikaday: A friendly guide to front-end date pickers

https://pikaday.dbushell.com

by mnemonet • 8 months ago

302 143 8 months ago

pikaday.dbushell.com

carlosjobim4• 8 months 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• 8 months ago

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• 8 months 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• 8 months ago

This should be higher up. Posting a deprecated library with this title is an interesting choice.

SoftTalker2• 8 months 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.

carlosjobim4• 8 months 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• 8 months ago

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

17186274406• 8 months ago

The browser, called the User Agent (UA), IS the program the user uses to interact with a website according to his preferences.

macintux• 8 months ago

Maybe. How many users change the defaults, or even know it’s an option?

sedatk4• 8 months 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.

Klaster_1• 8 months ago

How do you configure Firefox to show date-time picker in 24h format?

kmoser2• 8 months 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• 8 months 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• 8 months ago

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

ChadNauseam• 8 months 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.

dotancohen7• 8 months ago

I work with a factory that uses 32 hour timestamps, as some employees work a night shift.

pasc1878• 8 months ago

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

jandrese• 8 months ago

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.

cubefox2• 8 months ago

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

kmoser2• 8 months ago

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

parpfish• 8 months ago

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.

pimlottc• 8 months 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• 8 months 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• 8 months ago

Do you think there is anything missing from <input type="week"> or <input type="month"> other than Firefox support?

culi3• 8 months 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

[1] https://github.com/web-platform-tests/interop/issues?q=is%3A...

TZubiri• 8 months ago

I want an AI that channels the force of Chronos the greek god of time

Onavo• 8 months ago

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

vswaroop04• 8 months ago

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

BhavdeepSethi• 8 months 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• 8 months 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• 8 months ago

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

sevenseacat2• 8 months ago

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

tumidpandora• 8 months ago

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

franga2000• 8 months 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.

Muromec3• 8 months 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• 8 months ago

Agreed. This works way better than struggling with date pickers not working on mobile, finding where the year picker is etc etc

tshaddox• 8 months 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.

padjo5• 8 months ago

Input type date shows a calendar: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

mattmanser4• 8 months 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.

dotancohen7• 8 months ago

Tell us more. Please.

Telaneo• 8 months ago

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?

burningChrome• 8 months ago

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.

dotancohen7• 8 months ago

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.

Muromec3• 8 months ago

Which is why locale settings exist and are important to get right before asking for user input

stefs• 8 months ago

it's obviously the 3rd of september 1980, but without the 0-padding it looks icky.

fluoridation• 8 months 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• 8 months 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.

abanana5• 8 months 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• 8 months 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.

padjo5• 8 months ago

Why were you using a calendar picker for a date of birth?

abanana5• 8 months 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">.

HugoTea2• 8 months ago

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/

abanana5• 8 months ago

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.

bob1029• 8 months ago

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.

NooneAtAll3• 8 months ago

the year just looked like a heading. Nothing whatsoever suggested it was a tappable UI element.

IT IS TAPPABLE???

jrochkind15• 8 months ago

I feel like I have had trouble figuring out how to jump years in those too!

vintagedave• 8 months ago

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.

abanana5• 8 months ago

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.

frisbee6152• 8 months ago

Just use a slider, duh

cies• 8 months 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).

rkagerer3• 8 months 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.

dotancohen7• 8 months 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)

rkagerer3• 8 months 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.

hollowturtle• 8 months 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?

steveharrison2• 8 months 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.

steveharrison2• 8 months 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• 8 months 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_awareness2• 8 months ago

Is Pokemon popular in Denmark?

self_awareness2• 8 months 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• 8 months 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.

pflenker2• 8 months 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.

carlosjobim4• 8 months 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?

pflenker2• 8 months 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.

joelanman2• 8 months ago

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

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

antman• 8 months ago

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

dairylee• 8 months 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/...

carlosjobim4• 8 months 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....

jrochkind15• 8 months 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• 8 months ago

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

adornKey• 8 months 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.

NoSalt• 8 months 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• 8 months 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• 8 months 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• 8 months 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

Pikaday: A friendly guide to front-end date pickers

Related Stories