ravenstine
8 days ago
I know I will probably get pushback over this, but CalDAV sucks. People say that it's great and that it's easy; yet if that were true there would be way more self-hosted CalDAV solutions out there and they would be far more ergonomic than what's available. I was not impressed with Radicale. Because there's really only one calendar file I wanted to serve to myself, I tried implementing my own CalDAV server just for that purpose and pretty much gave up because of how unintuitive and complicated it was merely to make a single file available. I can see why it would be needed if sharing a calendar with other people with calendar apps that support CalDAV, but I think it's kind of a waste of time if hosting a calendar for one's self.
Instead, initially went with the approach of hosting my dynamically updating iCal file in an S3 bucket and using ICSx5 on Android to sync with it. No CalDAV needed – just HTTPS.
However, FOSS calendars for Android still suck, and for some reason I couldn't get ICSx5 to work within GrapheneOS, so I now use almost the same approach but with Proton Calendar which happens to support calendars from direct links to iCal files. It's not perfect, but it suits my needs enough.
I think the author's approach for using iCalendar format is a good one, though what I've discovered is the amount of support for various iCalendar features varies drastically between calendar software. Rather than dealing with that headache, I somewhat gave up and decided to shove most metadata into the description field rather than use the respective properties.
EDIT: My use case is software I wrote to grab data from various sites (Eventbrite, Meetup, pub trivia companies, public event calendars, etc.), filter for only social events I would be interested in, and combine them into a single calendar I can view in my normal calendar software.
kridsdale1
8 days ago
I worked on the CalDAV client that’s in every Apple product.
I agree, the protocol sucks. But we also had a ton of trouble handling Exchange and Google’s non-compliant CalDAV server, which all the users blamed us for.
Now that I work at Google I can see that gCal apps use an entirely different protocol.
bflesch
8 days ago
Would be nice if you use your experience and financial stability of a Google job in order to build a better open-source protocol. Just like when ZX2C4 decided he's fed up with OpenVPN and went to create Wireguard this might be your moment to shine.
IMO the quality of software is only pushed forward by motivated individuals with the right skillset.
rsto
8 days ago
The JMAP for Calendars RFC [1] is soon to get published by IETF. Disclaimer: I work for Fastmail and am the co-author of RFC 8984 [2] which defines the calendar event data model used in JMAP.
[1] https://www.ietf.org/archive/id/draft-ietf-jmap-calendars-22... [2] https://www.rfc-editor.org/rfc/rfc8984.html
conradev
8 days ago
Are the protocols compatible enough such that someone could proxy JMAP to CalDAV?
rsto
8 days ago
Yes, but I am not aware of an existing proxy implementation that would accept JMAP requests and forward these to a CalDAV server, or the other way round.
What I do know for sure is that it‘s feasible for a calendar server to service both JMAP for Calendars and CalDAV. All our work in that regard is open-source in the Cyrus server [1] and is used at Fastmail.
Apart from the exchange protocol one also needs to convert between iCalendar and the data structures used in JMAP. For this, I am currently working on an IETF RFC [2]. Anyone also interested in implementing conversion between iCalendar and JSCalendar, please contact me! We have a test suite for interoperation tests.
[1] https://github.com/cyrusimap/cyrus-imapd [2] https://datatracker.ietf.org/doc/draft-ietf-calext-jscalenda...
kridsdale1
8 days ago
It was 14 years ago, I’ve forgotten everything by now.
To be honest if I were to do that today, I’d vibe-code it by writing a strong set of tests against the protocol rfc, then a client against the tests. The client would be low level and have higher level interfaces in various languages.
philsnow
8 days ago
bflesch might be suggesting that you (or some other motivated + heroic person) write a new spec for calendar collaboration, like what jmap.io is trying to do for mail.
I know that calendars and datetime management suck, hard. I hazard a guess that several people have already started trying to replace caldav (because of the suckage of caldav) and have quietly given up (because of the suckage of datetimes and timezones).
kridsdale3
8 days ago
Indeed they do. The hardest bugfix I ever had to do (which I go back to whenever interviews ask that question) was a timezone bug that was going to ruin the iOS 7 on-stage reveal. It only reproduced in customer builds and customer hardware, which we could not debug or get root on. Anyway we traced it to a confluence of rare conditions in a date-math C file that had not been modified since 1987, and was in a completely different style from everything else in the OS. The edge-iest of edge cases.
It was hard because of the debugging blindness, not so much date-math itself. We had to do hardware-level things.
fc417fc802
8 days ago
I thought the solution to datetime was almost always to use TAI plus a library to convert for display in the UI. (Or UTC and accept that leap seconds might cause bugs.)
thequux
8 days ago
Calendar apps expose all of the weird edge cases in dates and times. For a specific instance of a specific event that never needs to move, TAI will work. However, suppose that you schedule a meeting for 28 March at 13:00. You then move that meeting forward a week, crossing a DST switch. If you simply add 604800 seconds to the TAI, that meeting will be at 14:00, which is surprising. OK, easy enough to solve; convert the TAI back to the local timezone, add 7 to the day field (carrying into month and year, as needed), and you're good to go. Now suppose that the meeting was set up in the US, and you realized that you needed to reschedule the meeting while you were travelling in Germany. You get back to the US, and suddenly the meeting is an hour early, because DST rules aren't universal.
Worse, imagine a recurring meeting, every week at noon. You've got the TAI for the original instance, but as you cross a DST boundary, some places will shift according to DST and others won't, and thus you have half the attendees showing up at the wrong time.
Finally, TAI introduces the leap second bug for calendars. When you schedule a meeting for noon next year, you want that to happen at noon, not now plus however many seconds. If a leap second is introduced, you don't want that meeting to happen at one second before or after noon.
TBH, if you find yourself in a situation where you need to deal with calendar events, I recommend updating your CV.
fc417fc802
8 days ago
I'll preface this by stating that I fully realize that localized datetime is absolutely byzantine and fraught with difficulties. That's the rationale for leaving it to an external library as close to 100% of the time as possible.
I also realize that there might well be complexities involved in calendar software that I'm unaware of. Hence my comment - I'm genuinely interested to learn. That said, I think your examples are all fairly clear examples of errors in reasoning by the programmer. Specifically they stem from conceptual mistakes regarding the relation of different logic domains (by which I'm referring to storage, display, scheduling, etc).
You never move events around in TAI (the unambiguous storage format) just as you don't go manually flipping bits in an SQLite database. You always work in a localized time because that's what the user is reasoning in. And you use the datetime library to implement as much of those manipulations as possible.
> US vs Germany, conflicting DST rules.
Go back to the era before smartphones and PDAs and the internet. You're in Germany on a business trip. You call your secretary to reschedule next weeks meeting back home. You don't use German time when doing that, you use US time.
Events have a location which has a timezone. Scheduling happens in that timezone. Blindly using the current local timezone of the device is a reasoning error. Storage, scheduling, and presentation are distinct logic domains.
> you have half the attendees showing up at the wrong time.
There is a single unique TAI time for a given event (after all that's the entire point of using UTC or TAI or what have you). All attendees will see an equivalent local time barring a bug in the datetime library.
See my earlier point regarding which timezone to use for the computation.
> TAI introduces the leap second bug for calendars.
Only if you make the mistake of attempting to manually manipulate your data storage format. The point of TAI as opposed to UTC in this specific case is to offload the complexity of handling leap seconds onto the datetime library so that you don't need to worry about it.
ElectricalUnion
8 days ago
> You never move events around in TAI (the unambiguous storage format) just as you don't go manually flipping bits in an SQLite database.
You actually do. From the point of view of future scheduled events, a event scheduled for 13h00 in a specific timezone is still "13h00 in a specific timezone" even when crazy people on that timezone suddenly declare a new Daylight savings time to start before the event happens. All future "timestamps" are prone to move due to such shenanigans. And you need to keep your timezone DB as updated as possible to update thing as soon as possible, if you don't want users with wrong times on their future events.
If you're not doing something like full rfc9557 https://datatracker.ietf.org/doc/html/rfc9557 "Internet Extended Date/Time Format (IXDTF)" [iso 8601 local time + as-of-now known timezone offset + IANA timezone] as "timestamps" you're probably truncating important information that will bite you back later if you're doing a calendar/scheduler.
fc417fc802
8 days ago
It's a good point. I responded to the adjacent comment.
After glancing at that RFC I'm unclear about the purpose of the UTC offset. Is it simply an error check to catch the case of a datetime library with outdated timezone information? Otherwise it seems like the library will have all the historical information on hand so it shouldn't have any use for it.
et1337
8 days ago
The problem is TAI is not the source of truth in real life. In real life, Arizona can change its laws and suddenly that event is going to happen at a different TAI timestamp. That’s why the unambiguous storage format has to be a date time with time zone, and not just a timestamp.
fc417fc802
8 days ago
Good point. Seems I also made a reasoning error by failing to consider that timezones, being arbitrary legal constructs, can be changed at the drop of a hat.
However it doesn't seem particularly difficult to fix. My error was suggesting using TAI for storage. I guess that works only for events in the past. So the timezone that the event belongs to is what should have been used for storage, you should forget leap seconds exist because this is a human centric calendar so who cares, and you should trust the datetime library to just do the right thing when converting timestamps.
Is there some other issue I'm missing? Because so long as all the timezone complexity is stuffed into the datetime library (and thus NotMyProblem™) it seems like the really difficult part is already solved for you.
funcDropShadow
7 days ago
In practice it is difficult enough, to do the right date arithmetic using the datetime library in the right timezone.
toast0
8 days ago
IMHO, based on zero evidence, for scheduling, very few people are scheduling events beyond a minute of precision. TAI is a better timescale than UTC, but UTC is better supported and leap seconds might be going away, so pretending they don't exist is probably a better choice.
But timezones are super byzantine. Especially when the rules update. More especially when the rules update on short notice.
If you scheduled an event at 5 pm local time at some place on some day and the rules change, the event's UTC (and TAI) would change. But you may want to confirm with the user, because maybe they're calling into an event somewhere else and they entered their local time but the event is really scheduled in the other time.
You might also have fun when multiple clients are using the same event and the clients and the server don't all agree on timezone definitions. iCalendar suggests that the timezone definition be included in the files, but my experience is definitions are often missing and most things ignore the definitions if present; you've got to include a timezone name the software is going to process as you want or you won't have a good time (or use UTC and hope)
If the event was scheduled in the DST window, the time may no longer exist, or may be ambiguous. iCalendar has rules for that, but they might not actually meet your user's needs (otoh, who is scheduleding things at 2-3am on a Sunday ... probably not a lot of people)
fc417fc802
8 days ago
> the clients and the server don't all agree on timezone definitions
Isn't that scenario unsalvageable regardless? It presumably means one or more of the devices are displaying the wrong time to the user. Or at least will be upon arrival in the timezone of the event.
For example (intentionally extreme) suppose the library used by my calendar thinks EST is -4, the OS on my device thinks EST is -6, and everyone else thinks EST is -5. What possible program logic could prevent disaster in this scenario?
It's a really interesting edge case to point out, I'm just not clear what a sensible algorithm for handling it would look like. I strongly suspect that assuming that can never happen is the right answer. Everyone agrees the event is scheduled for 9 am EST. If outdated client software translates that to PST incorrectly or displays the incorrect time on the clock then the affected user is going to have issues and I don't see what the programmer can realistically do about it.
> ... DST window, the time may no longer exist, or may be ambiguous.
Assuming the timestamp disambiguates the daylight timezone from the standard timezone this should be handled gracefully by the datetime library since the stale timestamp is merely "out of bounds" for that timezone now that the laws changed. I'm failing to think of a scenario where it becomes ambiguous (although reasoning through this is once again reinforcing my view that we should have ditched DST long ago).
However this did cause me to realize that there's an additional edge case for far future events where the timezone is modified multiple times. If the event timestamp was never updated in the interim you land in an ambiguous situation and have no way to detect it.
I'm not sure that particular edge case is worth worrying about, but it seems like tracking a second timestamp indicating the last time that the event was processed by the datetime library would resolve it. The library should hopefully have all the necessary historical information on hand to update a long since stale timestamp (I haven't tested this though). Anyway if it doesn't I don't see that there's anything you can do about it.
_hyn3
7 days ago
"Would be nice if you use your.. financial stability of a Google job to build an open-source protocol"
Well, sure, it'd be nice if we could all spend our time building things to give away for free, but it's just not always possible. Life happens and people shouldn't have to explain or apologize for it.
m463
8 days ago
kridsdale1
a day ago
This is one of those xkcd index numbers I know exactly the mapping of when I see the url.
noirscape
8 days ago
I think the core issue with CalDAV (and by extension, the protocol it's build on top of, WebDAV) is one somewhat endemic with most W3 approved standards: it's way too overengineered to do too many things at the same time rather than a lean format.
The result is a protocol that's essentially become a furball of different ideas mashed together, which inevitably leads to the situation where a lot of services just... don't try to be full spec compliant since it's out of scope for what they actually want to do.
I don't think I've ever seen a W3 data format spec that didn't end up this way, it just always seems to happen. (It doesn't seem to happen with their lower level protocol specifications.)
tannhaeuser
8 days ago
WebDAV is what it is because it's designed (largely by Julian Reschke who also took over the HTTP spec from TBL back then I believe) to be addable conflict-free and routable without complex payload inspection to existing HTTP services/practices. Its use of XML can be regarded over-engineered, but it follows what was available and considered adequate at a time that had much much more consideration for interoperability and multi-party buy-in than is even conceivable today. I wouldn't dismiss it so quickly, especially considering WebDAV is an IETF RFC not W3C spec to begin with.
mercutio2
8 days ago
WebDAV is pretty darn simple.
It just builds on actual HTTP, i.e. you have to actually think about the transport layer in a way that’s out of fashion now.
And some people don’t like XML.
It’s certainly true that CalDAV specifically is complicated, but… multi user calendaring is intrinsically very complicated.
Other systems are not less complicated, they just tend to be more vendor specific.
mbreese
8 days ago
The book Dreaming in Code [1] goes into great detail about how CalDAV (and WebDAV) came about through the work of the group who built the Chandler calendar program (or tried to). It’s been a while since I read it (at least 15 years), but I think it partially discusses some of the ways a protocol like this can get lost in committees during the design process. The fact that this project started around 2001 should also be informative about how long calendaring has been a problem. So, if you’d like to know about why it sucks, I’d recommend it.
It’s also a good story about the conflict between startups and open source, building products, and software development in general.
[1] http://www.dreamingincode.com/ ; https://en.m.wikipedia.org/wiki/Dreaming_in_Code
aklemm
7 days ago
Very good book. I read it way back when as well.
yonatan8070
8 days ago
I use Nextcloud's CalDAV and CardDAV with DAVx5 and it works pretty much perfectly
Jnr
8 days ago
I also use Nextcloud as the backend and iOS Calendar app as frontend on mobile and Gnome Calendar as frontend on PC.
It mostly works great, except for 3rd party Office365 calendars imported into Nextcloud. It has issues with some events on some clients displaying correct time when event invitees are from different time zone.
jp191919
8 days ago
I've been using Nextcloud as well for about 5 years now, and using Etar on my android. It's been great.
EbNar
8 days ago
Nextcloud calendar is a bit annoying in my case, as email reminders often come late, sometimes 10 minutes or more. I guess it's because they rely on the cron process.
edg5000
8 days ago
My CalDAV provider is ZOHO.
To sync with Android I use DAVX5 which runs a background sync service (open source and non-root). I had a lot of issues getting it working, could be because of different CalDAV implementations. DAVX5 to ZOHO calendar sync takes forever.
Evolution on Ubuntu has pretty good CalDAV support, but it would refresh the entire calendar each time upon switchin between the mail view and calendar view. Refreshing that ZOHO calendar takes forever and ZOHO has pretty frugal rate limits, so it ends up soft-banning me.
Latest Thunderbird has a CaldDAV incompatibility where it expects a different HTTP success code. ZOHO gives a 200, but Thunderbird expects something else. (PS Thunderbird CalDAV code is written in JS). PS This only happens on the second calendar. Whenever you add a second one, it starts failing.
So it is quite a pain, at least with ZOHO.
mxuribe
7 days ago
I also use zoho (for mail, calendar, contacts) for my family and I...and yeah the first time i set it up with DavX5, it was odd to say the least...though not sure if it was zoho's fault, or maybe both some possible glitch with zoho and DavX5, that didn't quite jive with my brain - at first. Now, i see no issues with Davx5 and zoho cal and contacts...at least it sync really well on my android phone. I have not tried Evolution for years (and certainly not with zoho yet), since i tend to default to thunderbird...But am about to set up my partner on one of the Gnome-based linux distros once their Windows 10 dies later this year...and considering how they like to use their computer and their workflow, gnome seems most appropriate for them, so have been considering suggesting for them to us Evolution as email client...so will be interesting to see how zoho works there. (Glad to hear it works for you!) As i noted, i like to use thunderbird, and as far as mail and calendar, actually i guess i have been lucky, since zoho seems to be working great for me - and for a couple of years now! However, contacts synching has never worked right - like, never at all. Sure i can export contacts from zoho and import them into thunderbird...so the issue is not the basics of contacts functionality within thunderbird per se...but the syncing between t'bird and zoho is certainly an issue, and have not had a chance to dive deeply enough to see if the issue is a t'bird issue or zoho...although like calendaring on my android phone, contact synching is not an issue with zoho from my phone (again via Davx5)...so, i'm confused. But, agreed with your points: i'm happ[y zoho customer, but they're not perfect...then again, at their low costs, i kinda can't complain too much. ;-)
NoTeslaThrow
8 days ago
> Instead, initially went with the approach of hosting my dynamically updating iCal file in an S3 bucket and using ICSx5 on Android to sync with it. No CalDAV needed – just HTTPS.
Well you also can't integrate this into most calendars. I don't even know what the hell an iCal file is. I haven't even heard "iCal" in what feels like decades.
> I know I will probably get pushback over this, but CalDAV sucks.
All the alternatives are worse.
ravenstine
8 days ago
Short for iCalendar. (.ics files)
Suppafly
8 days ago
[flagged]
NoTeslaThrow
8 days ago
> I'm not even sure you're qualified to comment then.
I'm qualified to point out that this is a hugely dickish way to communicate
woleium
8 days ago
Come on folks, be nice, we are all here to learn.