I failed moving my Google calendar to Proton
shilin.ca
shilin.ca
You're doing Lord's work here. Thank you. OAuth2 has been the bane of my existence; it's basically the One Weird Trick to Prevent Automated Use of a Service.
> 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/calendarin...
Then there is the “falsehoods programmers believe about time” list: https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b... , with some counter examples: http://www.creativedeletion.com/2015/01/28/falsehoods-progra...
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.
All good until summer time kicks in and your recurring 9am meeting now starts at 8am, oops.
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.
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.
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?")
Also, the existence of this thread should be good evidence that it is indeed not that simple.
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.
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.
if all_day_event:
show_option("timezone invariant")
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.
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.
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?
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.
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
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))
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?
> When should the times be updated?
> What if a participant uses multiple devices in multiple timezones at the same time?
I'll raise you a question
What do you do if this is not an all day event and is in a specific time?
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.
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.
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.
There is market for privacy; but the missing piece, after so many years, is how to synchronize calendars in a seamless way.
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.
"Perplexity is now available in Korean (한국어), Japanese (日本語), German (Deutsch), French (Français), and Spanish (Español)"
It's missing 3 of the top 5 languages spoken in the world today. It only has 3 of the top 10 most spoken languages in the world.
Also everyone in my country drives scooters and I don't see how voice commands are supposed to work with that kind of setup.
> Perplexity is now available in Korean (한국어)
> Also everyone in my country drives scooters and I don't see how voice commands are supposed to work with that kind of setup.
Being an ML researcher... I have some suspicions as to what is the root cause. I can't tell you exactly without having access, but I can tell you that it is VERY common for models to be trained without sufficient augmentation, let alone without sufficient diversity in data. So it is fairly common for the system to not be useful in certain environments. Worse, when you hyper focus on maximizing test data results you are extremely likely to perform data leakage (this is quite common and at this point I'd say you should assume it exists) and not enough evaluation on completely held out sets. Especially data which is significantly dissimilar to what you trained on (even when it is "in distribution"[0])
[0] This term can be a lot of things... so it must be interpreted in context.
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:
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.
But that's like the entire value prop of using Proton Calendar over the many other options out there, isn't it?
That's how I read it.
I love Proton, but there are aspects of E2EE that they haven't worked around well enough at present, in my opinion.
The biggest pain points are:
- Collaboration
- Offline access
So I ended up just self-hosting my calendar.
It's pretty easy to self-host a calendar, it can be as easy as dumping a bunch of PHP files on a server and connecting to a MySQL database (e.g. using Baïkal).
I have been using DuckDuckGo for years, both for searching and browsing. I love the ability to burn the cookies after each session!
But I haven't been able to replace Gmail, Calendar and Maps (which are quite good products IMO).
It's quite ironic that "google" (search) has become one of Google's worst products.
> To support much-requested features like tasks, search capabilities, and offline access, we’ve started work on our next generation of Proton Calendar apps for iOS and Android, which we aim to release toward the end of 2025.
I've had similar bugbears with their other products which end up in me not using anything except the core mail product.
They seem to improve things over time, but it's a game of patience.
E.g. I stopped using the Drive apps and only use it as an async backup store, because it keeps creating sync conflict files if you sync something you edit frequently (like an Obsidian vault). It also for some reason kept setting my user permissions to read only for my note files while it did this (on macOS).
I have not tried this, but there is some email obfuscation feature:
https://proton.me/support/pass-email-alias
and other email obfuscation services.
Not sure if this would matter for something like a calendar import, as I'm sure how the traversal works.
Also, the author could have tried a Murena /e/ os de-googled phone.
Glancing at my Murena /e/ os "App Lounge" there's dizzying number of calendar options with high privacy scores.
Also, doing some poking around and testing rather than going all-in on proton mail's calendar, esp. if calendaring is so important.
That said I use proton mail's calendar for everything personal and it works "ok" for me.
If you really want to “degoogle” you should probably go for self-hosting or getting a managed OSS product (e.g. managed Mailcow/Sogo Hosting). Otherwise you’re just switching from one crazy billionaire to another.
We can merely choose between which is the seemingly better known evil.
Self hosting is a way to go. It would be nice if one of those "no code" shops could make it a bit easier or something.
https://proton.me/blog/proton-non-profit-foundation
I do agree that self-hosting is best, but particularly for email, that's not trivial.
If so, have a no code site set up a mail host. It might still not be trivial but it might be much easier?
If this no-code stuff isn't a bunch of malarkey, it might be lowering the barrier to self-hosting that we've all been waiting for.
And self-hosting of email isn't quite "doing everything", it's doing one or two things.
It would be, to use your analogy, like growing your own tomatoes because Walmart's suck (and they do). Homegrown tomatoes don't have that "red leather" skin, a mysterious past, and may be quite inexpensive.
You can still get your Chinese made shirts, shoes, pants, and other inexpensive Chinese made goods at Walmart. But skip the Tomatoes.
Like lavabit or anon-penet.fi, cases where things go tits up for non-provider related reasons.
I actually agree, and personally I don't love how they advertise such foolproof security. It's dangerous especially when their non technical users don't understand the consequences. I've had multiple friends using Proton who think it's 100% private even when emailing a gmail user.
I recalled this when I read some crypto security efforts were focused on removing any javascript dependencies. I was like... hmmmm.....
Proton is secure. But it can be very hard to work with. I help seniors who were taken there by their more paranoid friends and associates and now struggle with the GUI and tying it into older mail clients
(It's worth noting for the privacy conscious that Australia, where Fastmail is based, has a truly terrible set of laws when it comes to government snooping, so if your threat model includes the Australian government, probably best to avoid Fastmail.)
It has also regularly been renewed and is still in full effect, and appears that it will remain so in perpetuity. It is the #1 most used source in US intelligence gathering.
Like Proton, it’s Swiss based, like FastMail, everything is using standard protocols. So unlike Proton, it’s just basic mail with no encryption but at least your mails are in a pretty safe jurisdiction.
If you care about it and use the webmail, the UX is pretty much ok but let’s be honest, FastMail is waaay ahead everyone else when it comes to usability. If you just use native clients to access your mail/calendar etc … it will just be the same.
It’s also a little cheaper than FastMail.
I self-host my own calendar, email, and contacts now.
You can probably do it on a raspberry pi or small NUC at home, with some port forwards over nebula/tailscale from a $5 VPS, if you wish.
I ended up moving to Fastmail, too. And if I'm moving email to FM, might as well move calendars.