Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pikaday: A friendly guide to front-end date pickers

pikaday.dbushell.com

Post reply on HN
Print view View original

21–30 of 146 posts

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

#21

Post by codegeek »

BhavdeepSethi wrote: post #18

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.

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

#22

Post by culi »

recursive wrote: post #13
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.

Do you think there is anything missing from or 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...

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

#23

Post by phil-pickering »

thoughtpalette wrote: post #15
nhumrich wrote: post #8

Earlier quoted context omitted.

From the GitHub project: > Pikaday was started before 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.

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

#24

Post by 1718627440 »

macintux wrote: post #17
1718627440 wrote: post #14

Earlier quoted context omitted.

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

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.

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

#25

Post by culi »

thoughtpalette wrote: post #15
nhumrich wrote: post #8

Earlier quoted context omitted.

From the GitHub project: > Pikaday was started before 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.

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!

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

#26

Post by 1718627440 »

evertheylen wrote: post #12
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).

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.

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

#27

Post by franga2000 »

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.

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

#28

Post by bklyn11201 »

culi wrote: post #22
recursive wrote: post #13

Earlier quoted context omitted.

Do you think there is anything missing from or 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.…

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.

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

#29

Post by solidsnack9000 »

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.

I think it is more common for them to write 8:00 to 25:00 - omitting AM and PM.

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

#30

Post by jandrese »

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

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

Post reply on HN