5 ms·

> I don't think it's unreasonable to want to be able to specify a meeting in London, on July 1st 2030, at 6pm local time - no matter what happens to UK timezone

> I don't think it's unreasonable to want to be able to specify a meeting in London, on July 1st 2030, at 6pm local time - no matter what happens to UK timezones between now and then. What's unreasonable is wanting this to be one piece of information. Location and time are distinct concepts that need to be split up. A timezone is not a location. Timezones are just a subjective shorthand convenience for display purposes, not actually tracking time. The reason the abstraction sucks is because the idea sucks.

Affric 3y ago
> The reason the abstraction sucks is because the idea sucks. Got it in one. Relativity, universal time, the human circadian rhythm... To quote my all time favourite HN comment quoting Plautus (presumably taken from R.R.J. Rohr's 1970 Sundials: history, theory, practice): > The gods confound the man who first found out how to distinguish hours! Confound him, too, who in this place set up a sundial, to cut and hack my days so wretchedly into small portions! When I was a boy, my belly was my sundial — one surer, truer, and more exact than any of them. This dial told me when ’twas proper time to go to dinner, when I had aught to eat; But nowadays, why even when I have, I can’t fall-to unless the sun gives leave. The town’s so full of these confounded dials the greatest part of the inhabitants, shrunk up with hunger, crawl along the street. — Plautus (c.254-184 BC) [1] https://news.ycombinator.com/item?id=30045114 https://news.ycombinator.com/item?id=30045114
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 ago
  Oops 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 ago
    The 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.
yardstick 3y ago
So what is the solution? How does set an appointment to meet someone in London, on July 1st 2030, at 6pm local time? Date time + lat/long?
- sublinear 3y ago
  If they really meant in London, and not just "London time", then yes. The lat/long can be used by the client side as needed to determine the user's locale, if the meeting is actually in London anymore, or indeed if London itself even exists anymore!

Affric 3y ago

> The reason the abstraction sucks is because the idea sucks. Got it in one. Relativity, universal time, the human circadian rhythm... To quote my all time favourite HN comment quoting Plautus (presumably taken from R.R.J. Rohr's 1970 Sundials: history, theory, practice): > The gods confound the man who first found out how to distinguish hours! Confound him, too, who in this place set up a sundial, to cut and hack my days so wretchedly into small portions! When I was a boy, my belly was my sundial — one surer, truer, and more exact than any of them. This dial told me when ’twas proper time to go to dinner, when I had aught to eat; But nowadays, why even when I have, I can’t fall-to unless the sun gives leave. The town’s so full of these confounded dials the greatest part of the inhabitants, shrunk up with hunger, crawl along the street. — Plautus (c.254-184 BC) [1] https://news.ycombinator.com/item?id=30045114 https://news.ycombinator.com/item?id=30045114

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 ago
Oops 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 ago
  The 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.

yardstick 3y ago

So what is the solution? How does set an appointment to meet someone in London, on July 1st 2030, at 6pm local time? Date time + lat/long?

sublinear 3y ago
If they really meant in London, and not just "London time", then yes. The lat/long can be used by the client side as needed to determine the user's locale, if the meeting is actually in London anymore, or indeed if London itself even exists anymore!