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

131–140 of 146 posts

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

#131

Post by jrochkind1 »

badestrand wrote: post #101
mattmanser wrote: post #84

Earlier quoted context omitted.

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 has nothing to with the dates being in the future and only with convention and labeling the field correctly. And in the table example you don't need the "where", because it's obviously in the restaurant's timezone.

If I want to book an appointment for April 12th 2027 at 2:00pm, then that's the time I want.

If my locale decides in 2026 to opt out of daylight savings time and not use it anymore -- it does not mean my appointment is now at 1:00pm instead. My appointment is still at April 12th 2027 at 2:00pm. But if I had saved it as a prediction of a UTC time in ISO 8601, then the system would think my appointment was now at 1:00pm.

This is why it has to do with dates being in the future. A past date-time can be converted to a UTC time represneted in ISO8601 that will not ever change (if it was converted properly).

I'm not sure where you got restaurants from -- you are the first person in this thread to mention restaurants? That is one use case for storing dates and times in the future, but certainly not the only one! There are of course some where the time zone is not "obvious". You realize there is software that's used for things other than restaurant orders and reservations, right? (Also I can imagine a restaurant that's a mobile food truck in an area near a timezone border...)

You speak very authoritatively and combatively about something I think you may not be on the same page about.

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

#132

Post by jrochkind1 »

seanhunter wrote: post #114
iso1631 wrote: post #111

Earlier quoted context omitted.

ISO 8601 timezone only allows an offset. You can't encode "04:00 in Cairo on 13th November 2036" as there's no way to know what UTC offset Cairo will have in October 31st 2036. > 2036-11-13 04:00:00 Africa/Cairo Is fine > 2036-11-13 04:00:00 +0200 Is not, as the rules around moving from +3 to +2 may well have changed by them.

That’s got literally nothing to do with ISO 8601 though. Times are just hard and there’s no way to know the future with any kind of certainty. In this case there’s no way of knowing whether Egypt will by 2036 have changed their timezone or added or eliminated DST. Nothing to do with ISO 8601, just the world is uncertain. Take the UK for another example. The daylight savings dates are actually set by act of parliament…

The fact that ISO8601 does not store time zones (only fixed UTC offsets, which is not the same thing) obviously has something to do with ISO8601. I'm not sure what you're going on about?

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

#133

Post by jrochkind1 »

dairylee wrote: post #90

I'm surprised the article doesn't talk about the element. It makes the using the native time input much more user friendly as you can populate it with common times (e.g. Every 30 minutes: 09:00, 09:30, etc... instead of allowing every minute to be selected by default) It's not quite fully supported in browsers but it's a nice enhancement to those where it works. https://developer.mozilla.org/en-US/docs/Web/HTML/Refer…

It does talk about datalist! Near the end. Maybe they changed the article and added it after you commented?

It doesn't say a ton about it. I'm interested in hearing more about usability of actual current browser implementations of these widgets, with dataalist but also in general.

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

#134

Post by rkagerer »

watwut wrote: post #112
rkagerer wrote: post #97

Earlier quoted context omitted.

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…

> The ordering is adaptable to locale This means that as a user, I have to toss a coin. The special 3/9 thing us that it can be either 9 March or 3 September. User locale is only loosely related to how user actually wants to have it or even assume to have it.

I should have clarified, by adaptable to locale I meant you have control via configuration.

The developer can supply a default or even lock it down. E.g. Users of the last app I built incorporating it always expected M/D and the app operated on a kiosk, so that's how we did it.

If no initial configuration is provided, the default does feed from the date format set up in the system locale settings. I agree in practice that's not always guaranteed to reflect what the user wants, but it is the intended spot the OS provides for configuring this and is usually the best source for a default: https://i.imgur.com/KShFPtb.png

If the developer hasn't locked it down, it's easy for a user to override (either via a setting exposed in the app - which you could even attach to a toggle right in the input field's context menu if you'd like, or via a config file / registry setting).

I missed the rot13 thing, and thought "Guveq bs Frcgrzore" referred to some kind of unique cultural event where dotancohen came from (like if I referred to 9/11 in the USA, or typed in "Thanksgiving").

Finally, you could also just type "Mar 9" for a one-off - or use the dropped-down GUI instead of typing anything in the box at all, if keying is not for you.

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

#135

Post by sedatk »

1718627440 wrote: post #106
sedatk wrote: post #104

Earlier quoted context omitted.

I mean the locale, not the language. Many web sites are in a single language and target a specific culture. I want that to be respected by the browser for input type=date and other similar elements based on web site’s language, not the other way around. That’s my preference.

What your browser calls a language, is in fact a locale. You specify en_US, not English. That would be equivalent to no setting a preferred locale or adding all the available locales.

Okay, I already have preferred languages selected: English and Turkish. If I visit a `` page I should see date inputs rendered in Turkish culture right? That's not the case unfortunately.

See it for yourself:

lang=en-US -> https://kod.ssg.dev/localetest/

lang=tr-TR -> https://kod.ssg.dev/localetest/index-tr.html

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

#136

Post by hunter2_ »

joelanman wrote: post #110
abanana wrote: post #108

Earlier quoted context omitted.

They don't appear to have tested a dropdown for the month name, with text boxes for date and year. I've read elsewhere in UX research that the month name should be preferred, for clarity, over entering another number. So it's unfortunate that that page's research isn't complete ("we will continue our testing") and doesn't appear to have ever been followed up.

(I worked on this pattern) Our guidance is to accept both names and numbers in the back end so people can enter either. In our testing, text inputs (with a numeric keyboard on mobile) is better than selects. Some people struggle with using selects, we don't see those issues in text inputs. That guidance maybe be about people not knowing the order of the inputs (DD MM YY, MM DD YY) but our pattern is clearly labeled f…

I'm not sure of every type of trouble folks might have using selects, but for the subset where using a hardware keyboard is required, you can usually type into a focused select just as you can type into a text input. Getting an Android/iOS on-screen keyboard to do this without a special configuration might not be a thing, I'll admit.

The only tricky part, for me, is deciding whether I should type a state abbreviation or a few letters of the full state name, which in my case differ enough to be quite annoying.

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

#137

Post by vintagedave »

abanana wrote: post #38

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

> a seasoned UX researcher like Don Norman

I get a real sense from some UX designers that following what he says is uncool. The vibe I get is one of how some people don't want to follow older people, with that 'we will do what we think best' sort of attitude. As thought UX is based on fashion not on concrete principles.

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

#138

Post by stefs »

dotancohen wrote: post #60
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.

it's obviously the 3rd of september 1980, but without the 0-padding it looks icky.

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

#139

Post by abanana »

vintagedave wrote: post #137
abanana wrote: post #38

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

> a seasoned UX researcher like Don Norman I get a real sense from some UX designers that following what he says is uncool . The vibe I get is one of how some people don't want to follow older people, with that 'we will do what we think best' sort of attitude. As thought UX is based on fashion not on concrete principles.

Yes, I totally agree.

I've seen a few youngish graphic designers calling themselves "UX designers" even though they have zero learning, experience, or apparently knowledge in UX. They're just copying fashions they think are "cool" while genuinely thinking they're doing something clever. They gave me the impression that they simply don't know UX is a discipline of its own with a long history of actual user-centric research.

It's a form of arrogance, determined they know best. On the rare occasions that they get to the feedback stage (rather than just rushing on to the next project), they've acted stunned when they realised that people have difficulty using something they designed, and they were absolutely determined that the user in question must be incredibly stupid. Thoughts of the usability of what they've built don't even enter their mind.

I'd like to hope these people are in the minority, but when I see poor user interfaces in so many different places, I'm not so sure.

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

#140

Post by dotancohen »

sevenseacat wrote: post #100
rkagerer wrote: post #97

Earlier quoted context omitted.

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

Exactly my point
Post reply on HN