[HN Gopher] Pikaday: A friendly guide to front-end date pickers
___________________________________________________________________
Pikaday: A friendly guide to front-end date pickers
Author : mnemonet
Score : 97 points
Date : 2025-11-11 14:58 UTC (8 hours ago)
(HTM) web link (pikaday.dbushell.com)
(TXT) w3m dump (pikaday.dbushell.com)
| carlosjobim wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| This should be higher up. Posting a deprecated library with
| this title is an interesting choice.
| phil-pickering wrote:
| 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.
| culi wrote:
| 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!
| SoftTalker wrote:
| 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.
| TheSisb2 wrote:
| Native datepickers fall apart when you need to handle different
| date formats as user preferences (not as browser default)
| 1718627440 wrote:
| The browser, called the User Agent (UA), IS the program the
| user uses to interact with a website according to his
| preferences.
| macintux wrote:
| Maybe. How many users change the defaults, or even know it's
| an option?
| 1718627440 wrote:
| 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.
| kmoser wrote:
| > 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 wrote:
| 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 wrote:
| 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
| 1718627440 wrote:
| And it is the right thing to do as otherwise the question
| to which day a train belongs will be confusing. Just take
| it %24hours before intersecting trains.
|
| It is also how I personally record time spans. It makes it
| much easier as you do not need to deal with the case where
| the start is larger than the end time and you can only have
| a single date field.
| ChadNauseam wrote:
| 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.
| solidsnack9000 wrote:
| I think it is more common for them to write 8:00 to 25:00 -
| omitting AM and PM.
| cubefox wrote:
| 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.
| koito17 wrote:
| In the case of Japanese, there is Wu Qian Wu Hou for
| 12-hour time. e.g. Wu Hou 9Shi niZhao ku (arrive at 9
| P.M.). If it's obvious from context, then only the hour
| is said. e.g. in[Ming Ri 3Shi nine] , 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.
| Zhao 6Shi niQi kiru (wake up at 6 A.M. / wake up at 6 in
| the morning).
| makeitdouble wrote:
| 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.
| SoftTalker wrote:
| Maybe at that point they should say "Closed 1am to 8am"
| instead.
| jandrese wrote:
| > 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.
| cubefox wrote:
| > 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".
| kmoser wrote:
| 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).
| pimlottc wrote:
| 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 wrote:
| 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 wrote:
| Do you think there is anything missing from <input type="week">
| or <input type="month"> other than Firefox support?
| culi wrote:
| 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...
| bklyn11201 wrote:
| 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.
| TZubiri wrote:
| I want an AI that channels the force of Chronos the greek god
| of time
| Onavo wrote:
| I wish there's a native calendly style time slot picker too.
| vswaroop04 wrote:
| Does it have options like multiple date pickups, pickups for a
| particular month only, and a yearly pickup?
| BhavdeepSethi wrote:
| 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 wrote:
| 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 wrote:
| Context: https://dbushell.com/2025/11/10/pikaday
| tumidpandora wrote:
| Great writeup, I think it'd be really helpful if this could be
| expanded to include handling timezones as well.
| franga2000 wrote:
| This is cool, but the last two just awful. The most annoying part
| of typing in credit card info is getting into the flow of typing
| in numbers from a card, then having to switch to "number to month
| name, then scan a dropdown", then to "convert two to four digit
| year and scan another dropdown of seemingly random length", then
| back to typing numbers for the CVC. On a computer, you need to
| switch between keyboard and mouse and back, on mobile your
| keyboard open and closes, reflowing the whole window and moving
| elements around a handful of times.
|
| In contrast to a "just type it" date picker (as in example 4) and
| staying in "just typing numbers" mode the whole time.
| Muromec wrote:
| 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 wrote:
| Agreed. This works way better than struggling with date pickers
| not working on mobile, finding where the year picker is etc etc
| tshaddox wrote:
| That's probably fine for dates that people have memorized, like
| their birthday. But it's certainly not great for something like
| flight search, where I might know I want to leave in early
| April on a Friday or Saturday. For that I really need to see a
| calendar not only to input a date, but to visualize the
| possible dates for my trip.
| padjo wrote:
| Input type date shows a calendar:
| https://developer.mozilla.org/en-
| US/docs/Web/HTML/Reference/...
| lukan wrote:
| Yes, but that is not what was recommended here above
|
| "my best advice is to use the damn input type text"
| fluoridation wrote:
| 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 wrote:
| The main practical problem here is that the "step" attribute is
| not widely supported so if you want the user to pick times in 30
| minute increments, it won't work.
| abanana wrote:
| A few years ago I wrote a mobile app for use by patients of local
| doctors' surgeries. This meant a higher-than-average proportion
| of older, less tech-savvy users.
|
| There was a flood of complaints about the OS-native date pickers,
| along the lines of: "There's no way to set the year! To get to my
| birth year, I had to tap the previous-month arrow 720 times!" (It
| seems people actually did this.)
|
| This is what happens in the real world when Flat Design takes
| over UI controls. On both iOS and Android (a few years back, I
| don't know whether they've been improved now), the year just
| looked like a heading. Nothing whatsoever suggested it was a
| tappable UI element.
|
| Now that mobile OS UI decisions are seemingly led entirely by
| aesthetics, instead of being run by a seasoned UX researcher like
| Don Norman, using an OS-native datepicker leaves the usability of
| our apps entirely at the mercy of what they choose to mess up
| next.
|
| I used Pikaday on a few websites years ago. We're told these
| tools are now obsolete - I wish that were true.
|
| (Changing the app to use textbox-dropdown-textbox for date-month-
| year - this is in the UK - stopped any further such complaints.)
| bigfudge wrote:
| It's not just old people that suffer. I'm slightly ashamed to
| admit I started the 100-tap process when I first used that
| input before realising it was dumb and googling what to do.
| They really are bad.
| padjo wrote:
| Why were you using a calendar picker for a date of birth?
| abanana wrote:
| 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">.
| frisbee6152 wrote:
| Just use a slider, duh
| cies wrote:
| 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).
___________________________________________________________________
(page generated 2025-11-11 23:00 UTC)