4 ms·
I don't see how the problems you mentioned couldn't be solved with storing clock time together with a location (or reading that time together with determining /
by sandblast 2y ago
I don't see how the problems you mentioned couldn't be solved with storing clock time together with a location (or reading that time together with determining / asking for a location), as was suggested here. Could you share your perspective on that solution?
- gregoryl 2y agoOff the top of my head; the user books a meeting at 2:30am, but local gov decides to implement a timezone change - time moves forward an hour at 2am. Does your meeting still exist?
- sandblast 2y agoThe software catches the problem during a search triggered by tzdata change, alerts the user and asks for clarification. Before user action, the meeting is considered to be scheduled to 3 AM. Is that scenario unreasonable?
- simonw 2y agoThat sounds right to me - for the 2-3am "time no longer exists" edge case you can apply a default pattern and ask the user to verify.
- lelandbatey 2y agoBecause users don't think about "time at a location" and they may not even have a location when they schedule a time. Both parties may say " yeah, meet at 4:30" with the knowledge that it could be my house in DST or your house in MST but we haven't decided yet, we'll figure that out in the future, but it'll be at 4:30. That's a time outside of a location which works for the humans involved but which is completely unresolvable by the "time at a location" computer paradigm. People do stuff like this all the time and don't think about it and it's unresolvable and not consistent.