8 ms·
It’s one heuristic, but you can’t know what they want, the problem is underspecified. It’s reasonably likely they could want a reminder to watch a game that is
by MobiusHorizons 4y ago
It’s one heuristic, but you can’t know what they want, the problem is underspecified. It’s reasonably likely they could want a reminder to watch a game that is being broadcast from a different time zone, or call a friend in a different country.
- toast0 4y agoThe user interface can be akward, but you can ask them for the timezone of the event. If it's for a live event in another place, they would ideally put in the local time in the other place and the timezone there. Or if it's a fixed time, not to be moved by DST changes anywhere, they could specify it in UTC. It's also a good idea to calculate and save the offset when editing. Then, if the offset changes later, you can notify the user. Hey, this appointment is affected by DST change, when do you want it to be?
- lifthrasiir 4y agoYes, many tz-related difficulties indeed arise from the future uncertainty and UX complexity to deal with that uncertainty. A conscious decision would be required and can't be easily delegated to someone else.
- macintux 4y agoI can’t even get employees at the company where I work to understand and communicate EDT instead of EST. I don’t think calendaring tools are going to have much success asking people what timezone they want.
- yorwba 4y agoThe stock calendar app on my Android phone (running LineageOS, so not sure how "stock" it really is) has a quite prominent time zone field when setting the time for an event, and I do use it quite a lot.
- delecti 4y agoI've mostly given up being pedantic about the difference between PT, PDT, and PST. Most people mean "PT" when talking about the time that work meetings are scheduled, but they say "PST" basically year-round, despite it being PDT more often than PST.
- kragen 4y agoIt's not a pedantic difference; if you calculate the time as PST when it's PDT or vice versa you'll be an hour off. Holding a meeting an hour early or attending it an hour late can have serious consequences.
- vxNsr 4y agoOP is calling it pedantic because most people mean PT. When someone says 9am they mean 9am regardless of the timezone, they’ll add the timezone if they’re talking with someone from a different timezone but still 99% of the time they mean 9am in their own timezone so if they’re in a region that observes dst even if they said pst they really meant pdt and you’re being pedantic by correcting them.
- delecti 4y agoI agree that it's an important difference, but being insistent about it is excessive because functionally those kind of mistakes just don't happen when scheduling meetings in Outlook, which is the context where it matters. Most of my work meetings only involve people in the same city, so there's no confusion there, and thus no scheduling problems. And 99% of the rest of my meetings are with people in Europe, and the relative difference between PST and CET is the same as the relative difference between PDT and CEST (though I do have to remind people twice a year that the two time zones change to/from DST a week or two apart).
- Volundr 4y agoIt is a pedantic difference. While it's technically incorrect to say PST when it's currently PDT, it doesn't inhibit communication. Both parties will understand it to be that "we meeting at 9am, whenever that happens to be for our California staff" as opposed to "we are meeting at 9am PST, even though no one is currently on PST" Even my colleague in Arizona is able to follow this despite them not joining the daylight savings time. Technically incorrect but in a way that doesn't inhibit understanding is the definition of pedantic.
- firecall 4y agoMy experience with Google Calendar, iCal and Outlook is that they do default to the meeting creators TimeZone. Which is often what we want! So on that regard, I find calendar invites rather than a causal email invite to be essential.
- AndreasHae 4y agoA lot of this could be solved by inferring the time zone by location of the appointment. If you know the event occurs in a specific place at a specific time, you almost certainly want it to be the standard time zone of that place. If that place uses DST, I couldn’t think of any reason to ignore it and opt for standard time regardless. Bonus: geopolitics change country lines, and that affects time zones as well. When the time zone at the appointment location changes due to border conflicts, you can get the new time zone without having to change anything.
- toast0 4y agoThat works if you know the location of the appointment. But if you're going to a bar to watch a televised game with friends, the location in the appointment is probably the bar, but the timezone is wherever the game is held. If you're going to have a conference call and you have a shared calendar system, great everybody should agree; if all the participants have separate calendar systems, maybe you discuss the time to have the call and each enter it in your local time, which works fine until someone's government adjusts local time on short notice. Having separate appointments sounds fragile, but have you had a good experience with cross domain calendaring? I certainly haven't. Never mind, if you had a fully booked schedule collaborating across timezones and someone's government adjusts local time, now you've got a mess.
- jkaplowitz 4y agoThere should also be a way to say "my current local time, whatever that may be", such as for events reflecting a personal daily routine for exercise, medicines, etc. This should adjust accordingly as the person changes time zone instead of staying at a fixed UTC offset.
- toast0 4y agothat's "floating time" and is definitely a valid option too, although for uses with multiple devices, now they've all got to agree on which timezone the user is currently subject to if you want a consistent experience.
- foepys 4y agoBut this is one more reason to save the timezone and stop calculating on current data? Save the time and timezone of the event in the other country, so literally the time it starts not the calculated local time. Unless the other country decides to switch timezones, well then you are screwed.
- tsimionescu 4y agoThat assumes you know what timezone the user intended. If I read somewhere that some football match in Chile is happening on November 1st at 1 o'clock, I may well put in a reminder for November 1st at 1 o'clock, without specifying a timezone or location. The calendar/reminder app would of course be unable to notify me that Chile's time for November 1st has changed, since I never told it anything about Chile.
- mason55 4y agoWhat exactly do you expect it to do? Asking the user for the location of the event for time zone purposes might be confusing but there’s no better option.
- tsimionescu 4y agoThe more common option is not to do that, and accept that in the rare cases of a timezone change, there's nothing you can do from software. Either way, the only completely fool-proof way to make sure you never return the wrong time is to ask not for a timezone, but for GPS coordinates, and preferably some extra cultural information - since the timezone of a particular location may change completely, and that change may only be recognized by certain entities. For example, when Russia annexed Crimeea, they could have changed the timezone (I believe they didn't, but they could have), but more nationalistic Ukrainians in Crimeea would have probably not recognized the timezone change. So, if someone had set an event for some time in the future and chose Ukraine's timezone, they may not have gotten the right reminder if the event was public (so presumably forced by Russian authorities to respect the new timezone), since you couldn't know they meant to watch something in Crimeea. To be clear, I'm arguing it's not worth trying to solve this problem in a fool-proof way in software, not that I expect software to help in situations like the above.
- nisegami 4y agoThen isn't the appropriate solution to store the time for that time zone?