4 ms·
"Whatever time 6pm is where we are" is a reasonable concept to want to express. You can't guarantee ahead of time when it will be, but it matters to people. Wh
by randallsquared 3y ago
"Whatever time 6pm is where we are" is a reasonable concept to want to express. You can't guarantee ahead of time when it will be, but it matters to people.
When I worked on a system that provided schedules for appointments, it was quite difficult to furnish a link that put this on someone's calendar reliably, and to set up reminders that went out every third Monday of the month at 9am to remind people to go to their clinic appt at 11am. People are equally annoyed at 8am or 10am reminders in such a case, so you can't tie it to a specific time, and daylight savings time gets changed from time to time, and various locations have "9am" at different times. We didn't even get into the weeds of whether someone who lives in Phenix City, AL should get notices in Central or Eastern (it's Eastern for most people, except if they work for the government or are going to school... unless it's a private school, which might still be on Eastern...).
Telling someone they can get their notice at any time they want as long as it's specified in UTC year round just doesn't solve the problem they have.
- sublinear 3y agoOops you're right. I forgot to also say that the date is not the time. The date can be stored together with the time as a timestamp, but all timestamps need to be in UTC. Getting the user's locale and applying their timezone is done on the client side. What matters to people stays on the client side.
- randallsquared 3y agoThe client might be a desktop app, a smartphone, a web browser (maybe in a public library, where they don't control the locale...), or just an SMS receiver. The only reliable place to apply these things is on the server, where you can look up the location of the appointment or event, and the preferences of the user, and apply whatever skew is appropriate.