←back to thread

Pikaday: A friendly guide to front-end date pickers

(pikaday.dbushell.com)
286 points mnemonet | 2 comments | 11 Nov 25 14:58 UTC | HN request time: 0.001s | source
Show context
kmoser ◴[11 Nov 25 18:44 UTC] No.45891157[source]▶
> Travel booking often has a fixed schedule with limited time options, such as every 15 minutes. Relative dates like “Today” and “Tomorrow” can be easier to understand.

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. (I often book flights right about midnight and find words like "today" and "tomorrow" to be completely confusing.)

replies(4): >>45891350 #>>45893047 #>>45893275 #>>45895437 #
cryptoz ◴[11 Nov 25 19:01 UTC] No.45891350[source]▶
Montreal public transit times used to be on some kind of like, 28-hour clock. Bus times after midnight would be labelled 27:30 or something. Suuuper confusing. It sounds so bizarre in fact, that I'm doubting my memory a bit, but I'm certain it was like that (say around 2006 or so).
replies(4): >>45891389 #>>45891959 #>>45894864 #>>45896920 #
1. evertheylen ◴[11 Nov 25 19:06 UTC] No.45891389[source]▶
This is actually how GTFS (a standard format for public transit data) works: https://gtfs.org/documentation/schedule/reference/#stop_time... . Especially sleeper trains can get weird with 30+ hours. But I don't think it's wise to show that to the user
replies(1): >>45892706 #
2. 1718627440 ◴[11 Nov 25 20:55 UTC] No.45892706[source]▶
And it is the right thing to do as otherwise the question to which day a train belongs will be confusing. Just take it %24hours before intersecting trains.

It is also how I personally record time spans. It makes it much easier as you do not need to deal with the case where the start is larger than the end time and you can only have a single date field.