5 ms·

A bit off topic but why are calendars so hard? I recently moved from android to apple and I'm just really impressed no one does a dedupe operation on calendars.

A bit off topic but why are calendars so hard? I recently moved from android to apple and I'm just really impressed no one does a dedupe operation on calendars. Seriously, who works on these things? I'll write you the regex if you really really need it but damn, if you're going to push fancy AI on me to make my life easier at least take care of all the annoying trivial bullshit that makes my life harder.

thih9 2y ago
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?) (…) https://techcommunity.microsoft.com/blog/exchange/calendaring-is-really-hard-to-code-and-that%E2%80%99s-why-you-were-an-hour-late-to-that-/1165583 https://techcommunity.microsoft.com/blog/exchange/calendarin... Then there is the “falsehoods programmers believe about time” list: https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b... , with some counter examples: http://www.creativedeletion.com/2015/01/28/falsehoods-programmers-date-time-zones.html http://www.creativedeletion.com/2015/01/28/falsehoods-progra...
- karamanolev 2y ago
  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.
  - pluies 2y ago
    > Storage in UTC and converting to a local timezone for display / notification purposes has been the standard practice for a looong time. All good until summer time kicks in and your recurring 9am meeting now starts at 8am, oops.
    - haakonhr 2y ago
      But summertime is a (at least here) a separate timezone, e.g., CET vs CEST
      - ivan_gammel 2y ago
        Timezones change.
      - deleted 2y ago
        [deleted]
      - happytoexplain 2y ago
        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.
  - ivan_gammel 2y ago
    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.
  - makeitdouble 2y ago
    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?")
- ivan_gammel 2y ago
  Timezone stuff is trivial with modern libraries like Java Time API. Event entity and event identity is hard.
- godelski 2y ago
  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.
  - OptionOfT 2y ago
    Weirdly enough an all day event in Office 365 isn't an all day event on a day. E.g, I record my wife's birthday in my calendar. I create an event on April 12th, and mark it as an all day event. What actually happens is that the calendar records an event that starts at midnight, and ends 24 hours later, and is marked as an all day event. But, when you change timezones the 24 hours actually shift, which can be very weird when you get notifications that are 6 hours earlier.
    - godelski 2y ago
      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. For whatever reason that is, it is bad business. [0] https://en.wikipedia.org/wiki/Eating_your_own_dog_food https://en.wikipedia.org/wiki/Eating_your_own_dog_food
- TeMPOraL 2y ago
  > 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.
ivan_gammel 2y ago
This is really a good question. Progress with calendars has stopped 10-15 years ago, the only major innovation relevant to it was Calendly, but that’s it. I guess it’s hard to imagine new features or even incremental quality updates as a viable business idea.
- jamalaramala 2y ago
  > I guess it’s hard to imagine new features or even incremental quality updates as a viable business idea. There is market for privacy; but the missing piece, after so many years, is how to synchronize calendars in a seamless way.
  - ivan_gammel 2y ago
    It’s not just that. Manual entry is still a thing happening too often. Yes, some apps allow to put your booking in a calendar, but that doesn’t cover all use cases. You call, make an appointment — getting an ical via SMS after the call would be great. You open a website, then check there the opening hours or schedule, taking that information to your calendar app would be great. Etc etc.
    - woleium 2y ago
      do you need that clutter on your calendar though, when a voice query to perplexity (or siri et al when they catch up) will answer your question about opening hours when you need the information?
      - ivan_gammel 2y ago
        Voice queries exist in a small bubble, most users in the world are not used to it. And of course AI may never be able to catch up with hyperlocal information that may not even be available to robots. As for the clutter, no, there won’t be clutter. There exists a conventional 3-view UI for calendars, but there can be more context-specific variants. E.g. separating awareness from booking on customer journey means that first I add a reminder with the opening hours and later calendar will present an opportunity to book.
ttepasse 2y ago
My pet theory is that it is the data model: everyone must support ical/Exchange and those only support events with a textual description. Events may be a part, but not the only part of a good calender. There is a lot of stuff which could be part of a calender but doesn't necessary fit into the event paradigm: Fuzzy events like the car inspection you are putting of. Transit times - not just the fixed time span you get today, but integration of public transport or current car traffic, so that you can plan. If you're menstruating a period tracker. Your health and sleep data. The weather, the day-night-cycle for your location. All background data with time and date, which we have, but not just in our calendars. And even traditional events are limited: I'd like to have a general repeating workday event but also like events in that workday as extra events. With a normal digital calendar they are clashing. Hierarchical events would be a solution. Or multi-layered events, some years back there was this blog post on HN which made me rather unhappy with iCal: https://julian.digital/2023/07/06/multi-layered-calendars/ https://julian.digital/2023/07/06/multi-layered-calendars/ https://news.ycombinator.com/item?id=36617504 https://news.ycombinator.com/item?id=36617504
- TeMPOraL 2y ago
  My pet peeve: buffer time. Or, rather, lack of it. Almost every calendar event requires some extra buffer time before and after, for things like getting to event location and back, and/or preparing, etc. No calendar app I've ever used even supports the concept, much less does anything to help. Right now, I resort to having a separate calendar for "buffer time" events, which I currently fill manually; I'm working on automating this, as almost all events also have fixed buffer time, that's known to me, but again there's no way to record that fact in existing calendar software.
  - godelski 2y ago
    This is a great point! And in the class of problems I was trying to illustrate. There's a lot of low hanging fruit here. We're programmers, we should be able to take our frustrations and turn them into solutions! If we're not, then we're doing something wrong lol. FWIW, in Apple Calendar there is an option for "Travel Time". This will prepend the event with some buffer value. When looking at the event on my calendar, in my iPhone, and ONLY in my iPhone there is a little : (vertical dots + car) symbol and saying (e.g.) "15 minutes travel time", while the event has a vertical continuous bar next to it. On my Macbook, the whole event is just expanded.[0] My pet peeve: dramatically differing interfaces between devices. I do understand that at times this must happen. But there's no reason for it to in this case. But worse than that, when CREATING a new event on my Macbook it is just so much clunker. I don't see "Starts" and "Ends" until I click on the time, where it instead expands. Then I can see the "travel time" option (in iPhone it is "Travel Time") and if I click the end time I can only select from a pre-determined time of 30min to 3hrs with 30 minute intervals. If I select "starts" I don't get this. In both cases I can __type__ the actual numbers in. [0] Update: while writing this comment, my macbook's calendar updated to show the vertical dots but does not include the little car nor the text (again with continuous vertical bar under actual event). Why did this take so long? "Just works" my ass. Arch linux has been more stable than trying to live by the Apple way.

thih9 2y ago

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?) (…) https://techcommunity.microsoft.com/blog/exchange/calendaring-is-really-hard-to-code-and-that%E2%80%99s-why-you-were-an-hour-late-to-that-/1165583 https://techcommunity.microsoft.com/blog/exchange/calendarin... Then there is the “falsehoods programmers believe about time” list: https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b... , with some counter examples: http://www.creativedeletion.com/2015/01/28/falsehoods-programmers-date-time-zones.html http://www.creativedeletion.com/2015/01/28/falsehoods-progra...

karamanolev 2y ago
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.
- pluies 2y ago
  > Storage in UTC and converting to a local timezone for display / notification purposes has been the standard practice for a looong time. All good until summer time kicks in and your recurring 9am meeting now starts at 8am, oops.
  - haakonhr 2y ago
    But summertime is a (at least here) a separate timezone, e.g., CET vs CEST
    - ivan_gammel 2y ago
      Timezones change.
    - deleted 2y ago
      [deleted]
    - happytoexplain 2y ago
      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.
- ivan_gammel 2y ago
  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.
- makeitdouble 2y ago
  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?")
ivan_gammel 2y ago
Timezone stuff is trivial with modern libraries like Java Time API. Event entity and event identity is hard.
godelski 2y ago
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.
- OptionOfT 2y ago
  Weirdly enough an all day event in Office 365 isn't an all day event on a day. E.g, I record my wife's birthday in my calendar. I create an event on April 12th, and mark it as an all day event. What actually happens is that the calendar records an event that starts at midnight, and ends 24 hours later, and is marked as an all day event. But, when you change timezones the 24 hours actually shift, which can be very weird when you get notifications that are 6 hours earlier.
  - godelski 2y ago
    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. For whatever reason that is, it is bad business. [0] https://en.wikipedia.org/wiki/Eating_your_own_dog_food https://en.wikipedia.org/wiki/Eating_your_own_dog_food
TeMPOraL 2y ago
> 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.

ivan_gammel 2y ago

This is really a good question. Progress with calendars has stopped 10-15 years ago, the only major innovation relevant to it was Calendly, but that’s it. I guess it’s hard to imagine new features or even incremental quality updates as a viable business idea.

jamalaramala 2y ago
> I guess it’s hard to imagine new features or even incremental quality updates as a viable business idea. There is market for privacy; but the missing piece, after so many years, is how to synchronize calendars in a seamless way.
- ivan_gammel 2y ago
  It’s not just that. Manual entry is still a thing happening too often. Yes, some apps allow to put your booking in a calendar, but that doesn’t cover all use cases. You call, make an appointment — getting an ical via SMS after the call would be great. You open a website, then check there the opening hours or schedule, taking that information to your calendar app would be great. Etc etc.
  - woleium 2y ago
    do you need that clutter on your calendar though, when a voice query to perplexity (or siri et al when they catch up) will answer your question about opening hours when you need the information?
    - ivan_gammel 2y ago
      Voice queries exist in a small bubble, most users in the world are not used to it. And of course AI may never be able to catch up with hyperlocal information that may not even be available to robots. As for the clutter, no, there won’t be clutter. There exists a conventional 3-view UI for calendars, but there can be more context-specific variants. E.g. separating awareness from booking on customer journey means that first I add a reminder with the opening hours and later calendar will present an opportunity to book.

ttepasse 2y ago

My pet theory is that it is the data model: everyone must support ical/Exchange and those only support events with a textual description. Events may be a part, but not the only part of a good calender. There is a lot of stuff which could be part of a calender but doesn't necessary fit into the event paradigm: Fuzzy events like the car inspection you are putting of. Transit times - not just the fixed time span you get today, but integration of public transport or current car traffic, so that you can plan. If you're menstruating a period tracker. Your health and sleep data. The weather, the day-night-cycle for your location. All background data with time and date, which we have, but not just in our calendars. And even traditional events are limited: I'd like to have a general repeating workday event but also like events in that workday as extra events. With a normal digital calendar they are clashing. Hierarchical events would be a solution. Or multi-layered events, some years back there was this blog post on HN which made me rather unhappy with iCal: https://julian.digital/2023/07/06/multi-layered-calendars/ https://julian.digital/2023/07/06/multi-layered-calendars/ https://news.ycombinator.com/item?id=36617504 https://news.ycombinator.com/item?id=36617504

TeMPOraL 2y ago
My pet peeve: buffer time. Or, rather, lack of it. Almost every calendar event requires some extra buffer time before and after, for things like getting to event location and back, and/or preparing, etc. No calendar app I've ever used even supports the concept, much less does anything to help. Right now, I resort to having a separate calendar for "buffer time" events, which I currently fill manually; I'm working on automating this, as almost all events also have fixed buffer time, that's known to me, but again there's no way to record that fact in existing calendar software.
- godelski 2y ago
  This is a great point! And in the class of problems I was trying to illustrate. There's a lot of low hanging fruit here. We're programmers, we should be able to take our frustrations and turn them into solutions! If we're not, then we're doing something wrong lol. FWIW, in Apple Calendar there is an option for "Travel Time". This will prepend the event with some buffer value. When looking at the event on my calendar, in my iPhone, and ONLY in my iPhone there is a little : (vertical dots + car) symbol and saying (e.g.) "15 minutes travel time", while the event has a vertical continuous bar next to it. On my Macbook, the whole event is just expanded.[0] My pet peeve: dramatically differing interfaces between devices. I do understand that at times this must happen. But there's no reason for it to in this case. But worse than that, when CREATING a new event on my Macbook it is just so much clunker. I don't see "Starts" and "Ends" until I click on the time, where it instead expands. Then I can see the "travel time" option (in iPhone it is "Travel Time") and if I click the end time I can only select from a pre-determined time of 30min to 3hrs with 30 minute intervals. If I select "starts" I don't get this. In both cases I can __type__ the actual numbers in. [0] Update: while writing this comment, my macbook's calendar updated to show the vertical dots but does not include the little car nor the text (again with continuous vertical bar under actual event). Why did this take so long? "Just works" my ass. Arch linux has been more stable than trying to live by the Apple way.