Pikaday: A friendly guide to front-end date pickers

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.

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.

> 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 Francisco time at 8.

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

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.

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.