Interesting - I think Office 365 had some sort of tempoprary export bug, as the appointments have all corrected themselves, and the TZID has changed for all appointments:
DTSTART;TZID=AUS Eastern Standard Time:20160714T120000
DTEND;TZID=AUS Eastern Standard Time:20160714T130000
Thanks @kralo for checking the iCalendar. The default type of DTSTART is indeed DATE-TIME, so @a3nm if you want to specify a DATE, use VALUE=DATE. If you didn’t generate the iCalendar yourself, please contact the one who generated it (and provide this thread as reference).
That is a lot more work than when your colleague tells you, please change the hostname or remove /test from the path. It is changes like that from refactoring or development process that are different each time. If this was to be supported, the cache should be cleared of course.
this was really just an idea to make icsdroid even more attractive and because I didn’t know about etag support in icsdroid. I just checked and most of my feeds do, I just wrote to teamup.com support to ask if they could add it
And it came to mind for the other use-case I described (respecting the cache-timeout header if the server sends one) because per-collection sync would be a prerequisite.
Honestly, icsdroid works great for me, this is just to foster it’s position as the best tool available 8-)
(a prerequisite would be to have per-collection sync intervals.)
Then you could respect http header meta-information, e.g. when it tells you how long this resource may be cached or when its expiring (and then trigger a new sync).
This could help save bandwith and computing time on the long run if servers send correct headers.
Yes, but the button is is appealing too. On https://icsdroid.bitfire.at/ the “Get it on Google Play” looks a bit lonely on the large gray square. On https://icsdroid.bitfire.at/download/ it is so far “below the fold” and in a different layout that I didn’t notice it. Hence that these buttons, with the same styling, give users of all stores in one quick look all they need to know on what stores this app is available. Understandable that you want a disclaimer since it is a build you don’t do yourself. However, it is a build that is monitored very strictly and openly, so I think you can list it proudly.
@max Synchronizing calendars in both directions is a very complex task, and it takes more than just downloading and uploading a single .ics file per calendar. If you have a look at CalDAV and which problems it solves, you will see what the problems are. You will also need a hierarchy: just think about the case that one .ics file contains a certain event, and the other doesn’t. So, does it mean that it has been deleted by the user and should be deleted from the one .ics file, too, or has it just been added and should be added to the other .ics file?