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

91–100 of 146 posts

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

#91

Post by Philip-J-Fry »

mattmanser wrote: post #84
Telaneo wrote: post #69

Earlier quoted context omitted.

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

Timezones change, more frequently than you realize. Some countries even used to change when summer time started regularly. It's got better than it used to be afaik. Also you need to take into account where the user is going to be. With future dates, time is relative. So at the very least you often need the time + the timezone of the location. Book me a table at 8, means book me a table in Berlin time at 8, not in San…

This is nothing to do with ISO 8601 though.

You can represent time zones with that format. So long as you have a source time zone, target time zone and tzdata you can convert any time accounting for all the particularities of any particular zone.

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

#93

Post by pjerem »

self_awareness wrote: post #81

Web devs should really discover that using standard native controls is the way to go. The worst thing that can happen to a website is to use a custom scrolling logic/scrollbar. It never behaves correctly. Next step would be discovering that we have been doing this since Windows 3.11, and we lost this ability because of web programmers.

I'm 100% with you except that modern native datepickers are awful. On iOS, selecting a date that is some years in the past or in the future is painful and entering the wrong date by mistake is really.

But I agree that it doesn't mean that it's up to the application developers to fix this.

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

#94

Post by __jonas »

padjo wrote: post #88
tlamponi wrote: post #75

Earlier quoted context omitted.

Obviously, but additionally, providing validation on the frontend can help UX a lot. Doing that can provide much quicker feedback compared to an error thrown at the user only after submitting a form, which can get especially annoying if the latter loses (some of) its values due to submission. And one solution for that problem can be using a native picker.

That is called input assistance, confusing it with validation is the source of millions of security problems.

That’s an interesting suggestion, but it is not, it’s called (client side) form validation

https://html.spec.whatwg.org/multipage/forms.html#client-sid...

I definitely see your reasoning for wishing it had a different name though.

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

#95

Post by abanana »

padjo wrote: post #87
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 .

Using a calendar picker to input dates that users have memorised and are in the distant past is an awful experience. This is a pet peeve of mine.

I think your point is just emphasizing how bad these native datepickers are. They are specifically used by the browsers for . Their purpose is to enter a date. That's why their use in this way is absolutely standard (far more so than the term "calendar picker" as far as I'm aware. The user's not choosing a calendar, they're choosing a date). That doesn't mean the choice of input method can't be improved, but highlighting it as a pet peeve won't make it happen at scale. What do you suggest instead?

The answer shouldn't be "create something custom for entering dates that don't happen to be in the current year", it should be "fix the datepicker so it's fit for purpose".

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

#96

Post by 1718627440 »

sedatk wrote: post #83
1718627440 wrote: post #77

Earlier quoted context omitted.

I also find this annoying, but this is due to websites ignoring the browser preferences. The browser supports specifying multiple languages and the website could select the one that the content is native in.

I don’t think there’s a browser setting that lets you use the locale the web site’s language in, is there?

You set all the language you want with priorities and the webserver knows it's own language and serves you the intersection with the highest priority. Or do I misunderstand your question?

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

#97

Post by rkagerer »

dotancohen wrote: post #63
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)

User pretty quickly recognize the picker accepts day & month. The ordering is adaptable to locale, and context can be provided to the control as to whether to favor past/closest/future occurrences (eg. bookeeping arrears vs planning future calendar event). Year can always be included if the users wants to be unambiguous.

I'm not familiar with the special 3/9 thing, but if you're serious that the behavior is something you think users in your locale would expect, then it wouldn't be hard to override the handler on a project using the picker and implement that.

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

#98

Post by badestrand »

abanana wrote: post #95
padjo wrote: post #87

Earlier quoted context omitted.

Using a calendar picker to input dates that users have memorised and are in the distant past is an awful experience. This is a pet peeve of mine.

I think your point is just emphasizing how bad these native datepickers are. They are specifically used by the browsers for . Their purpose is to enter a date . That's why their use in this way is absolutely standard (far more so than the term "calendar picker" as far as I'm aware. The user's not choosing a calendar, they're choosing a date). That doesn't mean the choice of input method can't be improved, but highlig…

I am so glad that so many people in this thread confirm how bad the native date pickers are; i thought I was alone.

Just picking the year is so difficult already on both Android and iOS as well as desktop Chrome, so a custom widget is immediately 100x better.

Yes, in theory it would be best to display the native picker because in theory it has a great UX, but in practice the native browsers' implementations are mostly just really, really bad, for whatever reason.

That's what I really dislike about the linked article - it doesn't even check the native implementations for their quality but just argues as if they are great.

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

#100

Post by sevenseacat »

rkagerer wrote: post #97
dotancohen wrote: post #63

Earlier quoted context omitted.

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)

User pretty quickly recognize the picker accepts day & month. The ordering is adaptable to locale, and context can be provided to the control as to whether to favor past/closest/future occurrences (eg. bookeeping arrears vs planning future calendar event). Year can always be included if the users wants to be unambiguous. I'm not familiar with the special 3/9 thing, but if you're serious that the behavior is something…

meaning, is it September 3rd or March 9th (or something else entirely?)
Post reply on HN