←back to thread

Pikaday: A friendly guide to front-end date pickers

(pikaday.dbushell.com)
287 points mnemonet | 2 comments | 11 Nov 25 14:58 UTC | HN request time: 0.004s | source
Show context
Muromec ◴[11 Nov 25 21:28 UTC] No.45893136[source]▶
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 invented this wipe his ass with fiberglass insulation for the end of times.

Don't get fancy and you will not fall down 10 rabbit holes that datepickers are.

replies(4): >>45893476 #>>45893538 #>>45894154 #>>45894848 #
mattmanser ◴[11 Nov 25 23:07 UTC] No.45894154[source]▶
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.

replies(3): >>45894852 #>>45895541 #>>45895570 #
Telaneo ◴[12 Nov 25 01:59 UTC] No.45895541[source]▶
> 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?

replies(2): >>45895987 #>>45897511 #
mattmanser ◴[12 Nov 25 08:04 UTC] No.45897511[source]▶
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 Francisco time at 8.

Same with displaying future dates, you need the context of where.

replies(2): >>45898479 #>>45898987 #
1. badestrand ◴[12 Nov 25 11:47 UTC] No.45898987[source]▶
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.

replies(1): >>45903349 #
2. jrochkind1 ◴[12 Nov 25 17:56 UTC] No.45903349[source]▶
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.