Pikaday: A friendly guide to front-end date pickers(pikaday.dbushell.com) |
Pikaday: A friendly guide to front-end date pickers(pikaday.dbushell.com) |
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.
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.
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
The project itself has been deprecated
This is an up-to-date guide demonstrating why the old deprecated Pikaday JavaScript Datepicker is no longer needed.
> Who needs a JavaScript date picker?
> The answer, in most cases, is nobody!
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.
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.)
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.
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.
IT IS TAPPABLE???
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.)
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.
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.
In contrast to a "just type it" date picker (as in example 4) and staying in "just typing numbers" mode the whole time.
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...
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).
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.
You inspired me to revive the project. Possibly remove the dependency and make it a usable datepicker.
Lyowforall: https://github.com/0xis-cn/lyowforall
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.
Everyone in my country uses the date format I just typed, to mean the date that I'm thinking of: Guveq bs Frcgrzore (rot13)
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.
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.
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/...
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 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.
How are we going to guess which date you want to take the train or flight?
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.
But I agree that it doesn't mean that it's up to the application developers to fix this.
~ Douglas Adams
I just can't reset my regional settings whenever I switch tabs.
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.
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
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.
But the same issue exists with explicit dates like "November 12".
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.
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.
Why is this the case? Is it some time zone shenanigans?
"my best advice is to use the damn input type text"
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.
We did continue our testing which resulted in the pattern in the design system which is linked.
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.
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.
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.
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).
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.
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.
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.
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.
> 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.
And in the table example you don't need the "where", because it's obviously in the restaurant's timezone.
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.
Or do you mean that ISO 8601 doesn't work but RFC 3339 does work or some other updated ISO/RFC format?
Someone else has mentioned RFC 9557.
So you might be able to deal with it with 8601 for past dates and 9557 for future.
That would be equivalent to no setting a preferred locale or adding all the available locales.
<html lang=...See it for yourself:
lang=en-US -> https://kod.ssg.dev/localetest/
lang=tr-TR -> https://kod.ssg.dev/localetest/index-tr.html
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".
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.
It is eye-opening to have not one but two devs challenge me, both seasoned accounts so probably experienced developers.
But I've dealt with the real problems it causes and they clearly have never touched future dates or they'd have already hit these problems. Or maybe the US's timezones are more stable than the EU's? I think between the two startups they had something like 2 million uniques a year, with bookings in the 100,000s, so not exactly huge scale either. And only operated in like 4 countries. But we still hit them.
https://html.spec.whatwg.org/multipage/forms.html#client-sid...
I definitely see your reasoning for wishing it had a different name though.
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.
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
2019-12-23T12:00:00-02:00[America/Sao_Paulo]
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.