Designing the Perfect Date and Time Picker (2017) | Hacker News Reader

Designing the Perfect Date and Time Picker (2017)

smashingmagazine.com

44 pointskaeruct10 comments

It makes me sad how so many of those examples are Month-Day-Year.

Imo the perfect date and time picker should respect ISO8601.

No, it should respect the locale settings of your browser.

In the case where you have text input, wouldn't the best approach be to support both the locale settings and ISO8601? Unlike M/D/Y and D/M/Y where dates can be ambiguous, as far as I know there's no locale where a locale-specific date and ISO8601 can be mutually ambiguous.

Yes, I agree, and everyone (devs) should think about who they’re really trying to make things easy for.

If you simply say follow the ISO standard you’re essentially making it easy for yourself and hard for the users. Sprinkle that with a drop down day picker as in the example, and you’re really in control of what the input will be. Not much chance of faulty input, right?

However, the ISO will not be relatable for many people and the drop down is a UI nightmare.

The user will be spending much more time with the form than devs (runtime), so this of thinking should definitely be avoided (during programming time).

On this subject: does anyone have an example of a time picker that supports unambiguously picking a time in the "fall back" hour in political timezones with daylight saving time part of the year? I've never actually seen one. It's only relevant for one hour out of the year, so you want it to be unobtrusive (maybe invisible) most of the time, and intuitive when it's relevant.

Most libraries like Java time choose the earlier timezone (summer) by default, but allow an override. If the date picker parses text you can usually force it to one of the two times pass explicitly setting the offset.

More than a couple of our vendors have been frustrated by my insistence that they properly support daylight saving time. Both switch overs have their own set of unique potential problems but if a vendor has an API as part of their product and we're going to build automation on top of it, this twice a year undefined behavior generator isn't acceptable. It surprises me how many companies seem to have an severe allergy to using UTC or even including TZ data with their time/date data.

At first I read "Designing the Perfect Date" and missed the rest of the headline. Now I'm disappointed because I was hoping for tips on how to design the Perfect Date for my girlfriend. So, any tips?

Reply on news.ycombinator.com