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

141–146 of 146 posts

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

#141

Post by mattmanser »

rendaw wrote: post #71
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?

And what format does work for future dates? Or do you mean that ISO 8601 doesn't work but RFC 3339 does work or some other updated ISO/RFC format?

I'm not dealing with it anymore, I was when I worked in a couple of restaurant focused SaSSes.

Someone else has mentioned RFC 9557.

So you might be able to deal with it with 8601 for past dates and 9557 for future.

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

#142

Post by mattmanser »

jrochkind1 wrote: post #131
badestrand wrote: post #101

Earlier quoted context omitted.

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:00p…

I did mention booking a table, because I used to work with restaurant booking.

It is eye-opening to have not one but two devs challenge me, both seasoned accounts so probably experienced developers.

But I've dealt with the real problems it causes and they clearly have never touched future dates or they'd have already hit these problems. Or maybe the US's timezones are more stable than the EU's? I think between the two startups they had something like 2 million uniques a year, with bookings in the 100,000s, so not exactly huge scale either. And only operated in like 4 countries. But we still hit them.

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

#143

Post by pflenker »

carlosjobim wrote: post #116
pflenker wrote: post #85

The best date picker is the one which doesn’t require picking a date. If done correctly, the browser can auto-fill your birthday, for example. In many other cases it’s possible and makes sense to guess a date and prefill the date field. Phones attempt the same with being biased towards entering the current date or datetime.

> The best date picker is the one which doesn’t require picking a date How are we going to guess which date you want to take the train or flight?

Easy. You have data available which tells you about the most likely travel dates, and you set this as the default. Many booking platforms pick a weekend in 2 weeks or something like that. This predefined field changes the task from entering a date to correcting a date, where the prefilled date is likely close to the desired date and thus requires less input/changes than starting from scratch.

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

#144

Post by seanhunter »

jrochkind1 wrote: post #132
seanhunter wrote: post #114

Earlier quoted context omitted.

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?

I’m saying the problem is the time zone, not the fixed offset. The fixed offset always means a specific time (which may or may not be the time in a particular place, due to problems with the definition of time zones). Times for dates in the future are a problem due to time zones, not due to offsets. If you know the offset, the time is exactly specified.

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

#145

Post by dotancohen »

rkagerer wrote: post #134
watwut wrote: post #112

Earlier quoted context omitted.

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

I've often wondered if Polish and rot13 English have similar letter frequency distribution.

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

#146

Post by 0xis »

edarchis wrote: post #128

It's funny to talk about internationalization but only support Western date format. If you are managing hospital admissions in Nepal, you have to be able to provide the date in Nepalese calendar and in the common one. And believe me, the Nepalese calendar is a complex one. In Ethiopia, you'll have to support 13 months but they'll be close enough to common dates that people will manage mentally. But imagine that you h…

Last year I was working on a calendar supporting multiple calendar schemes. Currently it is only dogfooded with fictional calendars and a demo with heavy Vue and UI library.

You inspired me to revive the project. Possibly remove the dependency and make it a usable datepicker.

Lyowforall: https://github.com/0xis-cn/lyowforall

Post reply on HN