Yes, this has been implemented about a year ago.

Here one current example: I schedule in August 2020 a meeting, targeted for Fuji, for 2020-11-11 and send an .ics invitation, bundling tz definitions. Afterwards the Fuji experts change DST rules, so that the switch does not happen on 2020-11-08 but on 2020-12-20. The UTC offset calculations, included in the .ics invitation, are therefore for that meeting wrong. Nobody thinks on regenerating and resending the .ics file with new tz data. If the OS gets updates, then that event might be presented correctly, if the .ics interpreter ignores the bundled TZ definitions, if the .ics interpreter sees no bundled timezone definitions, or if the .ics interpreter shows to the user, that the bundled TZ definitions are outdated, and there are two possible times for the start.

There is no ultimate right way on technical level to prevent troubles here, not bundling the time zone definitions in the .ics file saves band width.

See also https://techcommunity.microsoft.com/t5/daylight-saving-time-time-zone/fiji-dst-end-date-correction-update-now-available/ba-p/1669658 and https://techcommunity.microsoft.com/t5/daylight-saving-time-time-zone/interim-guidance-on-2020-time-zone-updates-for-fiji/ba-p/1766806 .

Is there any update on this? the 15 minute sync is way to slow for my use-case and I would love to implement own sync trigger…

It seems like the action is not going to be embedded in Tasker any time soon.

Hi,

If you click on “Show details” in the “No CardDAV/CalDAV service found”-dialog, you’ll see a full log with all information.

Hi everyone, first of all congrats on the fantastic app! 🙂

I think it would be a nice improvement if users could tell DavX to avoid syncing during certain time periods, e.g. overnight.

Currently, I’d prefer to have my syncing every hour, but the problem is this causes all of my server’s disks to wake up once per hour for the sync. During the day this isn’t too bad since the disks would often otherwise be awake, but overnight this causes lots of unnecessary disk wakes. It would be great if we could tell the app “only sync between 08:00 and 22:00”, for example, to avoid those unnecessary syncs.

My current workaround is set the syncs to happen every 4 hours, which helps with this issue a bit (only 1 unnecessary sync overnight generally). However, using this setting also makes my calendar pretty useless during the day unless I manually update all the time.

Anyone else think this is a good idea? 🙂

Hello,

Unfortunately, it’s not that easy. I guess you would have to exclude the dependency ical4j from ical4android and include a new submodule (= the downloaded local ical4j) instead.

@TheOtherDoctor A note on the brute-force approach which other apps (example: Synker) use - providing a (possibly power-draining) desktop widget just to enforce they maintain a handle to run processes which Android otherwise does not like them to… honestly, when having to decide to either further struggle with an unwilling device or just sacrifice a bit of runtime for now… the latter is a tempting alternative. 😉

@rfc2822 No, I am not totally sure the upgrade to 3.1.1 was already installed when I observed this, might have happened on a phone where an upgrade got stuck. When you cannot reproduce it, and did some changes in that direction lately, I’d consider my observation invalid now and not worth investigating further.

@devvv4ever I am aware that I should disable any power saving things (if I could only ever be sure I didn’t skip over the relevant one - different story); with the question I just meant that, when I encounter sync issues on that device with this specific topic, any changes to those appkiller settings currently will now help as long as the issue described above is not solved. That is, I understand by now that the missing sync setting items is not just a minor layout issue but actually reflects a disabled sync.

@devvv4ever Yes, there is always a bit of the orange box left to click on it, but the name of the account is hidden, so the only annoyance ever done is just having me open an wrong account, no big thing. About the account select fields, I am just wondering why not putting the name next to the icon, but this might be a different idea… later.

Finally, I have to admit I’ve just proven myself stupid - just when I was about to propose enabling minimizing or removing the warning message, I realized you did already. 🙂
Obviously I only ever tried to click on it to close, but never to swipe it, which I did first time now and which solves the visibility issue at no effort. Forget my whole comment. 😉

Short update, just for completeness, as meanwhile I could track this further down, and is probably limited to the (non-current) OS version: On a Lineage 14.1 device, I can reproduce the effect as follows: when I open one account, and then leave back with the arrow on top left, then and only then I get thrown back to the AppIntro. With using the system-“back” button instead, this does not happen.
Reproduced so far on two Lineage phones, does not happen on two stock android phones (also when based on same Android base version), thus I’d conclude it’s just a Lineage weirdness. 😉

Some services don’t automatically pull contact photos from other services (gmail, yahoo, gravatar, etc). I’d like to suggest a feature where DavX could check if there’s a contact photo associated with an email address (from one of these other services), and pull it in.

Options could be given to “never overwrite existing pictures, or Overwrite existing pictures”

This is finally addressed by https://gitlab.com/bitfireAT/ical4android/-/commit/f2a7e34cfc296abc18587923b854945704df59ce. Since DAVx⁵ v3.1-beta6, generated VTIMEZONEs are minified 🙂

Thanks for the response, @devvv4ever ! You raise some good points about duplicate contacts and merging algorithms, and I agree that such ideas are well beyond the scope of DAVx5. However, I have yet to find a FOSS (or even just freely-available) app that does a good job of simply copying contacts between accounts. Samsung may have one, but I don’t have a Samsung phone.

My plan for merging the CopyContacts app I linked into DAVx5 was to create a new DAVx5 contact store for any existing contact store the user wants DAVx5 to manage. Basically, like you, I also wanted to avoid the issue of contact merging. Sure, this would create a lot of extra accounts/contact stores, but it would at least allow existing contacts to be merged (and synced) by DAVx5.

Thoughts?

Just stumled over this issue. I do youth work and would like to add kids’“mother” -and “father”'s names to their contact. However, as discussed above, there is no “correct” translation from android to vcard which causes to become both a “parent” relation.

Here a test, how the android relation do resolve:

FN:Relationtest N:;Relationtest;;; RELATED;TYPE=co-worker;VALUE=text:Assistant RELATED;TYPE=sibling;VALUE=text:Brother RELATED;TYPE=child;VALUE=text:Child RELATED;TYPE=spouse;VALUE=text:Domestic Partner RELATED;TYPE=parent;VALUE=text:Father RELATED;TYPE=friend;VALUE=text:Friend RELATED;TYPE=co-worker;VALUE=text:Manager RELATED;TYPE=parent;VALUE=text:Mother RELATED;TYPE=parent;VALUE=text:Parent RELATED;TYPE=spouse;VALUE=text:Partner RELATED;VALUE=text:Referred by RELATED;TYPE=kin;VALUE=text:Relative RELATED;TYPE=sibling;VALUE=text:Sister RELATED;TYPE=spouse;VALUE=text:Spouse REV:20200511T200233Z END:VCARD

Why can’t you just make unclear relation type mapping a custom one, these way the data would actually not be changed with synchronisation which took me quite a time to find out. I always wondered, why these relation aren’t the same anymore on nextcloud after synchronisation.

I would like to suggest following the system default theme that is available from Android 10 (API level 29):
https://developer.android.com/guide/topics/ui/look-and-feel/darktheme

Thanks for changing the title for me.

As for the Qt-CalDAV thing - I totally understand that CalDAV doesn’t have anything to do with Qt or the way it interprets color values. Qt also doesn’t have any idea about CalDAV. If you asked me, then I would say that this is just a total coincidence that Korganizer correctly displays calendar colors sent by the Runbox calendar service. The support for SVG color names was implemented in QColor for totally different reasons, not with Apple’s calendar-color in mind (Qt as a programming framework just supports SVG as one of many graphics formats, that’s why QColor needs to understand SVG color names). QColor, of course, supports also RGB(A) color values. And most probably Runbox chose to use SVG color names for their calendars because it was just more convenient for them (we give users 120 predefined SVG colors for their calendars - they be happy; we have less work - we be happy as well).

Unfortunately, I also have no knowledge of the Apple’s calendar-color specification. From the DAVx5 logs I just assumed that these color names are Apple-defined and are part of their calendar-color specification. Turned out that my assumption was wrong. It seems that this caused a lot of unnecessary confusion 😀

Thank you, that was quite quick.

Well, you can set values there, how else could you update appointments - but I understand that there is probably no way to find out which calendar app made the entry in order to know whether they have to be corrected - or is there?

As stated before, it if was an empty field (like null) or if a distinct value like 0 was used and
1=tentative (thank you for the correct term)
2=approved
3=rejected

this could be recognized and there could be an (advanced) option in DAVx5 about how to handle that.

On the other hand if it is set to 0 and
0=tentative (thank you for the correct term)
1=approved
2=rejected

DAVx5 may not be able to distinguish an App that uses the 0 value correctly and apps like Business Calendar 2 and Samsung Calendar that have this issue.

And yes, I understand and agree that this should be fixed by the calendar app, but as this seems to be an quite widespread issue it would be nice to add a fix if it is similar easy as thought of in my post. I doubt that Samsung will fix it, as it has been around at least 1.5 years.

Thank you so much for the reply. I was not aware that for this to work, the CalDAV client had to write this into the remote calendar (and thus require a calendar with r/w privileges) - I thought it could be added only locally during sync.

I am actually using BC2, so I will give their birthday calendar implementation a spin.