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

61–70 of 146 posts

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

#61

Post by dotancohen »

mattmanser wrote: post #54
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…

Tell us more. Please.

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

#62

Post by dotancohen »

cryptoz wrote: post #11
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.)

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 work with a factory that uses 32 hour timestamps, as some employees work a night shift.

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

#63

Post by dotancohen »

rkagerer wrote: post #55

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…

What date is 3/9 in your date picker? I'm willing to bet it's not the date I'm thinking of.

Everyone in my country uses the date format I just typed, to mean the date that I'm thinking of: Guveq bs Frcgrzore (rot13)

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

#64

Post by carlosjobim »

SoftTalker wrote: post #45
carlosjobim wrote: post #2

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?

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.

The native date pickers are of low quality for usability. They have been so unpopular for so long, that you don't have any users who are accustomed to them. Because almost no apps or websites 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.

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

#65

Post by hollowturtle »

Except native date pickers still sucks on desktop, i really dislike the chrome version on macos and can't say nice things to the firefox one. Also browsers behave differently when trying to validate the date entered in the input, if you listen for on change event, chrome fires it as soon as a valid year is entered except if want to type 2025 starting with the 2 would result in 0002 on the input and... that's a valid year, what you do validate or not? wait for blur event to check the final entered date?

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

#66

Post by folmar »

nozzlegear wrote: post #58
folmar wrote: post #56

Earlier quoted context omitted.

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?

Even if, that does not help. When asked for a birthday I need validation of the date in country when I was born, not the country I'm in, not the locale I'm using for display and not the locale server/requesting company is in.

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

#67

Post by foresterre »

culi wrote: post #25
thoughtpalette wrote: post #15

Earlier quoted context omitted.

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!

I was quite confused too. I thought these were Pikaday implementations, partly because I usually use UK language in browsers, and then you get exclusively these (annoying to me) AM/PM date input pickers, and this time I didn't.

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.

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

#68

Post by parpfish »

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

i hate that computers define 'today' and 'tomorrow' on days centered on midnight.

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.

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

#69

Post by Telaneo »

mattmanser wrote: post #54
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…

> ISO 8601 does NOT work with future dates. It does not work with cross border appointment booking.

Why is this the case? Is it some time zone shenanigans?

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

#70

Post by burningChrome »

mattmanser wrote: post #54
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…

15 years a front-end dev, 5 years as accessibility engineer.

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.

Post reply on HN