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

51–60 of 146 posts

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

#51

Post by cies »

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

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

#53

Post by culi »

bklyn11201 wrote: post #28
culi wrote: post #22

Earlier quoted context omitted.

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.

It's simply not a priority. The Bugzilla has been open for 9 years. At one point the assignee of the bug simply stopped logging in and it took 7 months for the autonag to bother people. There simply aren't enough people asking for it. And the fact that it's a Chrome-exclusive feature means it's gonna take a backseat to features that Chrome AND Safari implement but are lacking in Firefox.

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.

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

#54

Post by mattmanser »

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…

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.

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

#55

Post by rkagerer »

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.

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

#56

Post by folmar »

abanana wrote: post #49
padjo wrote: post #47

Earlier quoted context omitted.

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

Could you explain what you mean? We're talking about the OS-native datepicker, which pops up when a user clicks on an HTML .

This is the place where the date picker does not help the user at all. It's easier to type the, presumably memorized, date, than to look it up in the calendar no matter how nice and handy the calendar is. Sure it does solve validation problem. Or maybe not correctly, don't ask about locales and date adjustments.

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

#57

Post by folmar »

cubefox wrote: post #32
solidsnack9000 wrote: post #29

Earlier quoted context omitted.

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.

And even if they have, representations of noon and midnight differ.

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

#58

Post by nozzlegear »

folmar wrote: post #56
abanana wrote: post #49

Earlier quoted context omitted.

Could you explain what you mean? We're talking about the OS-native datepicker, which pops up when a user clicks on an HTML .

This is the place where the date picker does not help the user at all. It's easier to type the, presumably memorized, date, than to look it up in the calendar no matter how nice and handy the calendar is. Sure it does solve validation problem. Or maybe not correctly, don't ask about locales and date adjustments.

Doesn't the browser automatically a handle locales when using the HTML5 input=date?

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

#59

Post by dotancohen »

folmar wrote: post #56
abanana wrote: post #49

Earlier quoted context omitted.

Could you explain what you mean? We're talking about the OS-native datepicker, which pops up when a user clicks on an HTML .

This is the place where the date picker does not help the user at all. It's easier to type the, presumably memorized, date, than to look it up in the calendar no matter how nice and handy the calendar is. Sure it does solve validation problem. Or maybe not correctly, don't ask about locales and date adjustments.

Date picker widgets do not solve any validation problem, because validation happens on the server side and client input is not to be trusted.

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

#60

Post by dotancohen »

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…

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.
Post reply on HN