The point is that it's far safer to assume that an unspecified time zone means 'local time wherever I am at the time of the appointment' than not. If I'm flying to Japan and meeting someone at 7pm, I'm going to make an appointment 'Izakaya at 7pm'. I definitely don't want the software to change that to 1am, and I cannot think of a use case where I would.
If you're in Istanbul, and you're going to meet at 7pm Izakaya time, why would you enter 7pm Istanbul time? Put 1am Istanbul time or, more sensibly, enter the appointment as 7pm Izakaya time.
I don't want my calendar changing appointment times on me. If I say 7pm when I'm in Istanbul, I expect it to alert at 7pm when I'm in Istanbul, 8pm if I'm in Dubai, 9pm if I'm in Karachi, and 1am if I'm in Izakaya. Entering it without a timezone should reasonably default to the timezone the calendar was in when the appointment was entered.
Let's take an example: suppose I have a calendar appointment to call my partner, at 7pm Istanbul time. I'm in Istanbul, and I enter 7pm with the "floating" scheduling method. Then, I travel to New Zealand, and at 7pm NZ time, alarm goes off, so I call my partner. Unfortunately, it is 9am in Istanbul, not 7pm: the floating screwed up the schedule. Including timezone in the appointment would have prevented this issue.
Let's take another example: you're in Istanbul, traveling to one of your company's remote offices in NZ for a week for a summit, and have your agenda set out in "floating" time according to NZ timezone. Then, a storm rolls in, and you can't fly out, so you'll attend the same appointments remotely. But now you must edit each and every appointment to reflect their new "floating" time according to Istanbul. Including timezone in the appointments would have prevented this issue.
I see what you mean, difference in floating time expectations between remote vs in-person appointments. A case of choosing your default poison, I guess. Thanks for pointing it out.
The point is that it's far safer to assume that an unspecified time zone means 'local time wherever I am at the time of the appointment' than not. If I'm flying to Japan and meeting someone at 7pm, I'm going to make an appointment 'Izakaya at 7pm'. I definitely don't want the software to change that to 1am, and I cannot think of a use case where I would.
If you're in Istanbul, and you're going to meet at 7pm Izakaya time, why would you enter 7pm Istanbul time? Put 1am Istanbul time or, more sensibly, enter the appointment as 7pm Izakaya time.
I don't want my calendar changing appointment times on me. If I say 7pm when I'm in Istanbul, I expect it to alert at 7pm when I'm in Istanbul, 8pm if I'm in Dubai, 9pm if I'm in Karachi, and 1am if I'm in Izakaya. Entering it without a timezone should reasonably default to the timezone the calendar was in when the appointment was entered.
Let's take an example: suppose I have a calendar appointment to call my partner, at 7pm Istanbul time. I'm in Istanbul, and I enter 7pm with the "floating" scheduling method. Then, I travel to New Zealand, and at 7pm NZ time, alarm goes off, so I call my partner. Unfortunately, it is 9am in Istanbul, not 7pm: the floating screwed up the schedule. Including timezone in the appointment would have prevented this issue.
Let's take another example: you're in Istanbul, traveling to one of your company's remote offices in NZ for a week for a summit, and have your agenda set out in "floating" time according to NZ timezone. Then, a storm rolls in, and you can't fly out, so you'll attend the same appointments remotely. But now you must edit each and every appointment to reflect their new "floating" time according to Istanbul. Including timezone in the appointments would have prevented this issue.
I see what you mean, difference in floating time expectations between remote vs in-person appointments. A case of choosing your default poison, I guess. Thanks for pointing it out.