Pikaday: A friendly guide to front-end date pickers • Hacker News Board

Re: Pikaday: A friendly guide to front-end date pickers

#31

Post by Muromec » Tue, Nov 11, 2025, 9:28 PM UTC

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.

Re: Pikaday: A friendly guide to front-end date pickers

#32

Post by cubefox » Tue, Nov 11, 2025, 9:36 PM UTC

solidsnack9000 wrote: post #29

ChadNauseam wrote: post #16

Earlier quoted context omitted.

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.

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.

Re: Pikaday: A friendly guide to front-end date pickers

#33

Post by cubefox » Tue, Nov 11, 2025, 9:42 PM UTC

kmoser wrote: post #4

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

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

Re: Pikaday: A friendly guide to front-end date pickers

#34

Post by fluoridation » Tue, Nov 11, 2025, 9:43 PM UTC

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.

Re: Pikaday: A friendly guide to front-end date pickers

#35

Post by recroad » Tue, Nov 11, 2025, 9:48 PM UTC

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.

Re: Pikaday: A friendly guide to front-end date pickers

#36

Post by makeitdouble » Tue, Nov 11, 2025, 9:49 PM UTC

ChadNauseam wrote: post #16

cryptoz wrote: post #11

Earlier quoted context omitted.

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

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.

Re: Pikaday: A friendly guide to front-end date pickers

#37

Post by kmoser » Tue, Nov 11, 2025, 9:50 PM UTC

cubefox wrote: post #33

kmoser wrote: post #4

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

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

Re: Pikaday: A friendly guide to front-end date pickers

#38

Post by abanana » Tue, Nov 11, 2025, 9:59 PM UTC

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

Re: Pikaday: A friendly guide to front-end date pickers

#39

Post by TZubiri » Tue, Nov 11, 2025, 9:59 PM UTC

sureglymop wrote: post #6

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.

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

Re: Pikaday: A friendly guide to front-end date pickers

#40

Post by throwaway7783 » Tue, Nov 11, 2025, 10:00 PM UTC

Muromec wrote: post #31

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 i…

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