It’s difficult to maintain basic features in a popular calendar, at least according to the ms exchange team blog:
> calendaring is particularly tricky. Why’s that? Well, consider time zones for a start – a meeting you set up isn’t necessarily in the same time as it is for me, and then you also invited people, from a whole bunch of other time zones (did you know some time zones are 30 mins off, not a full hour?) (…)
I don't buy it. I do think the problems are not trivial but it's not like there aren't trivial problems within the larger problem.
Let's take a trivial problem: holidays. Every account you have comes with a holiday calendar. So if you got a Microsoft, Google, and Apple account you'll have entries in triplicate. These are all day events with identical names. There's a lot of hints to tell you that these are identical and you only need to display 1.
A bit harder would be birthdays. These might not be in a unique calendar. But the word "birthday" is a huge hint when it's an all day event.
I do agree that defaulting to a position of not destroying data is best (though here we'd never destroy data). But that doesn't mean we can't offer users assistance. We do have the capacity to let users merge events or in some way note that they are identical.
One more issue, why the fuck can't I move an event from my Google calendar to my Apple? In the worst case, just copy the damn thing and then hide the event. You can do this even when you don't have write access to the Google calendar.
So the thing I don't buy is that we can't do more. A programmer's job isn't easy. But it involves problem solving. I think there's not enough grumpy yet motivated people who will voice up such things because management usually says that it's not important. But these non important things add up. Life is complex so the little things actually matter a lot.
Sounds like something that could be solved by a flag.
if all_day_event:
show_option("timezone invariant")
If it is timezone invariant, then you can make it the 24hr (or whatever because there might not be 24 hrs in a day...) period relative to the current timezone.
This isn't an unsolvable problem, it is just people not seeking solutions.
I have a theory: a lot of tech products suck today because either:
- People are not dogfooding[0] (using their own products)
- People are not raising concerns
- People raise concerns but issues are de-prioritized in favor of more flashy things.
None of these things are great and they can only happen while a company has significant marketshare and monopoly like status. In essence, it is internal rot. Someone (plural) is disconnected from the actual product. They are out of touch with what the users want.
And I mean here's the thing. I could go ahead and write a wrapper for all of this and wrap in all my calendars. But that's a ton of work, there's probably no market, but if there was a market then the realistic result is that my success would result in the big players implementing the same feature and thus devaluing my work even though I increased the value of theirs. So I can do this as an open source project, but boy are there a lot of other higher priority issues like this. The real problem is that these issues can't be resolved within these big companies.
> make it the 24hr (...) period relative to the current timezone
What if the event gets shared - should the dates still be relative to the timezone of the creator? Or to the most popular timezone? Or should they be different for everyone? Or something else?
What if the event is recurring and the creator travels between the occurrences, should the times change? When should the times be updated? Should all events change, or only the future events, or only the closest one?
What if a participant uses multiple devices in multiple timezones at the same time?
…etc. Perhaps there are ways to solve all these and more; my point is that in the context of calendars even adding a flag can get complex fast.
> What if the event gets shared - should the dates still be relative to the timezone of the creator?
You mean
What if the event gets shared with someone who doesn't have a calendar that implemented this hypothetical yet super basic and highly useful feature.
Well then, it falls back to the standard 24 hr block, right? Yeah, it would be the timezone that it is currently being shared from because our flag was just telling the event to move itself with the timezone instead of being static.
Is that really that bad? This doesn't sound like a reason not to do this. Because the worst case scenario is that... we end up with the current implementation...
> What if the event is recurring and the creator travels between the occurrences
Here's some shitty pseudocode. You could do this and store as UTC time but I think storing with timezone makes the point clearer.
class Date(...):
def __init__(self,
year : int = 1970,
month : int = 1,
day : int = 1,
hour : int = 0,
minute : int = 0,
second : int = 0,
...
tmz : str = "PST",
**kwargs):
super().__init__()
...
def start_of_day(self):
self._hr, self._minute, self._second = self._sod
def end_of_day(self):
self._hr, self._minute, self._second = self._eod
class Event(...):
def __init__(self,
start_time : Date, # date event begins
end_time : Date, # date event ends
all_day_event : bool = False, # is all day event
tmz : str = "PST", # timezone
tmz_invar : bool = False, # timezone invariant
**kwargs):
super().__init__()
...
self._begin = Date(start_time, tmz=tmz).start_of_day()
self._end = Date(end_time, tmz=tmz).end_of_day()
if all_day_event:
self._begin = self._begin.start_of_day()
self._end = self._end.end_of_day()
self._ade = all_day_event
self._tmz_invar = tmz_invar
class Calendar(...):
...
def display_events(self, ...):
...
for event in self.events:
if event.timezone_invariant:
self.display(event._begin._sod,
event._end._eod)
else:
self.display(event._begin.tmz_offset(self.current_tmz),
event._end.tmz_offset(self.current_tmz))
All day events are marked as starting at the beginning of a day and ending at the end of a day. That being from our Date structure, which holds Month, Day of month, hour, minute, second, whatever precision, as well as special things like when the beginning of the day is and when the end of the day is. Here the function start_of_day() and end_of_day replaces whatever input values for {hour, minute, second, ...} with the appropriate values and attributes _sod and _eod are those values.
This assumed you stored events as a time with a timezone. If you stored events in UTC you'd need different logic. I mean time is messy, but either way we're moving stuff around. I mean we're just _displaying_ offsets when moving timezones, right? Because it would be wild to update all events every time we moved timezones, right? So we have to do some logic to take the date and display it relative to its time
With a timezone invariant flag all we're doing is saying
Look at the year, month, and day. Ignore time and instead, use the day's start time and end time.
> What if the event is recurring and the creator travels between the occurrences, should the times change?
No, IT IS AN ALL DAY EVENT
> When should the times be updated?
They don't, IT IS AN ALL DAY EVENT
> What if a participant uses multiple devices in multiple timezones at the same time?
Doesn't matter, IT IS AN ALL DAY EVENT
I'll raise you a question
What do you do if this is not an all day event and is in a specific time?
Think about that answer.
It is really not a hard problem. Because you are storing the events in some database. Moving timezones is then a conversion process. The invariant flag is just saying "keep the time relative to the day."
> my point is that in the context of calendars even adding a flag can get complex fast.
I don't disagree, but I'm failing to see where this specific issue is an actual problem.
Speaking of - hiding events is one of the features of Sectograph[0] I most frequently use. I think local event modifications on shared calendars are another big feature missing almost everywhere. In my case, hiding events lets me just sync the shared family calendar synced directly to my watch, and just hide the events I don't care about, as to not clutter the display, without deleting or otherwise affecting what my wife sees on her devices.
> So the thing I don't buy is that we can't do more. A programmer's job isn't easy. But it involves problem solving. I think there's not enough grumpy yet motivated people who will voice up such things because management usually says that it's not important. But these non important things add up. Life is complex so the little things actually matter a lot.
In Admiral Adama's voice: So say we all.
--
[0] - https://sectograph.com/ - may seem like a bit weird gadget, looking at the app screenshots, but it's true value comes from the same circular view being available as a watch face, giving you always-available view of the next 12 hours on your wrist. This is why I started adding bus/tram departures and event buffer times to my calendars - they become useful for quick checks on the go. IMHO, it's the only actually useful watchface on the Android smartwatch market.
Which is exactly why Google had to fuck it up with their Watch Face Format idea, aka. Manifest V3 For Smartwatches, aka. removing "smart" from "smartwatch". Fortunately, I'm not forced into it until my current watch dies.
> It’s difficult to maintain basic features in a popular calendar, at least according to the ms exchange team blog:
There's a large amount of things that regular people do with calendars every day, that could be automated or managed through better interaction paradigms, and to which those issues don't apply. That's a lot of low hanging fruits, that everyone's leaving to rot.
Like:
> meeting you set up isn’t necessarily in the same time as it is for me, and then you also invited people, from a whole bunch of other time zones (did you know some time zones are 30 mins off, not a full hour?)
99% of my calendar use involves events happening within days or weeks, and concerning me alone, me and my wife, me and my acquaintances, or me and some random local company. I don't care about timezones for those - they all happen in the same one, with the same DST shift.
(The remaining 1%? Timezone shenanigans happen at few distinct points in a year, and everyone knows to be careful around those and communicate out-of-band if needed. So again, not an issue in practice for users like me.)
Microsoft is thinking about calendars as tools for employees of multinational corporations. But calendars aren't only useful for managers frequently flying intercontinental; there's a lot of regular folks using them for affairs much more localized in time, space, and social graph.
Eh, I don't buy that. Storage in UTC and converting to a local timezone for display / notification purposes has been the standard practice for a looong time.
What I would believe, I don't know if true, is that different applications support subtly different feature sets, integration has varying levels of support and correctness and so on. Additionally, I feel like vendors are incentivized to offer good support within their ecosystem, but integration with the outside world is a second-class citizen.
"Just store it in UTC" will cause bugs for human time, which calendaring is the most complex example of (because it contains basically every other use case). Don't throw away the date and time the user entered. How you store it is the subjective part, as different choices have different risks. But don't just throw it away.
Also, the existence of this thread should be good evidence that it is indeed not that simple.
Storage in UTC is generally wrong for future events and doesn’t make sense at all for unbounded sequences.
Edit: better approach will be to store event as it was defined and include processing hints, e.g. when next UTC time of occurrence can be reliably established.
The point is that humans want a meeting's clock time to change when they travel to a new time zone, but not when their local time changes (either due to DST or a legal change).
Unless of course not everybody invited shares the same DST patterns, in which case it has to change for some of the participants (how do you choose which?).
Also, the relationship between the datetime the user chose and the UTC time you store can be retroactively changed by legislation.
UTC storage is standard practice, but not the best practice nor something that solves all the major issues a good application should be dealing with.
I'd qualify it as "good enough to not get fired" grade of decision, for people who don't care that much about calendaring in the first place or have the luxury ignore complex cases (we're back to "why are calendars so hard?")
Let's take a trivial problem: holidays. Every account you have comes with a holiday calendar. So if you got a Microsoft, Google, and Apple account you'll have entries in triplicate. These are all day events with identical names. There's a lot of hints to tell you that these are identical and you only need to display 1.
A bit harder would be birthdays. These might not be in a unique calendar. But the word "birthday" is a huge hint when it's an all day event.
I do agree that defaulting to a position of not destroying data is best (though here we'd never destroy data). But that doesn't mean we can't offer users assistance. We do have the capacity to let users merge events or in some way note that they are identical.
One more issue, why the fuck can't I move an event from my Google calendar to my Apple? In the worst case, just copy the damn thing and then hide the event. You can do this even when you don't have write access to the Google calendar.
So the thing I don't buy is that we can't do more. A programmer's job isn't easy. But it involves problem solving. I think there's not enough grumpy yet motivated people who will voice up such things because management usually says that it's not important. But these non important things add up. Life is complex so the little things actually matter a lot.