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

111–120 of 146 posts

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

#111

Post by iso1631 »

Philip-J-Fry wrote: post #91
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 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.

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

#112

Post by watwut »

rkagerer wrote: post #97
dotancohen wrote: post #63

Earlier quoted context omitted.

What date is 3/9 in your date picker? I'm willing to bet it's not the date I'm thinking of. Everyone in my country uses the date format I just typed, to mean the date that I'm thinking of: Guveq bs Frcgrzore (rot13)

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.

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

#113

Post by johnisgood »

__jonas wrote: post #94
padjo wrote: post #88

Earlier quoted context omitted.

That is called input assistance, confusing it with validation is the source of millions of security problems.

That’s an interesting suggestion, but it is not, it’s called (client side) form validation https://html.spec.whatwg.org/multipage/forms.html#client-sid... I definitely see your reasoning for wishing it had a different name though.

I do understand what "client-side" validation is, but I wish it had a different name, because people think they can just validate client-side and they do not bother doing it on the server... for some reason, I do not know. It should be obvious though, right? Yet it is not.

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

#114

Post by seanhunter »

iso1631 wrote: post #111
Philip-J-Fry wrote: post #91

Earlier quoted context omitted.

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.

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. Although they always have fallen in the pattern that everyone knows, for dates in future years beyond the ones they have already set, they could hypothetically (if you want to be literal-minded about it) change the law to make DST happen on absolutely any day of the year or not at all.

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

#115

Post by carlosjobim »

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

This is a nightmare everywhere I have seen it implemented. I cannot think of any situation or use case where this is not the worst solution possible.

In one system we use, you have to scroll through a 12000 pixel tall list of 15 minute increments. And you can't type to search, because they use AM/PM....

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

#116

Post by carlosjobim »

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?

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

#117

Post by Muromec »

iso1631 wrote: post #111
Philip-J-Fry wrote: post #91

Earlier quoted context omitted.

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.

Are you scheduling a restaurant reservation for 2036? Will it change from 09 to 10 in the morning depending on DST?

Sure, we cant know what unix date it resolves to, but it doesn't matter, because future dates are more of a contract intentionally bound to context that is subject to change.

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

#118

Post by Muromec »

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.

Which is why locale settings exist and are important to get right before asking for user input

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

#119

Post by iso1631 »

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…

ISO 8601 only allows timezones as offsets, not as locations.

If it allowed "Africa/Cairo" instead of "+0200" that would be fine.

> they could hypothetically (if you want to be literal-minded about it) change the law to make DST happen on absolutely any day of the year or not at all.

That's the whole point - that's why you store future date/times with the location, not the offset, and not in UTC

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

#120

Post by PaulDavisThe1st »

kmoser wrote: post #37
cubefox wrote: post #33

Earlier quoted context omitted.

> Except when you're booking a flight and you're not sure whether "today" is based on your local time, the server's local time, or GMT. But the same issue exists with explicit dates like "November 12".

Not really, because the standard in air travel is that departure and arrival dates and times are always local to the departure or arrival airport, regardless of where you are when you book the flight (or what time it is locally when you book).

and yet google calendar by default translates them into the current (GPS-based) timezone ....
Post reply on HN