As we have heard, the problem has been solved on the server side by modifying the VTIMEZONE definitions.
Recurring events before year 1902 are not shown in calendar
its hard to search for such specific issues in here so hope this wasn’t reported before.
DAVdroid 1.3.1 from F-Droid
Cyanogenmod 13 (latest nightly) with default calendar
Steps to reproduce:
- Having a working ownCloud 9.0.5 installation
- Create a contact with a birthday like 01.01.1900 (had chosen 1900 for contacts where i don’t know their birthdays)
- Configure DAVdroid to “All events will be synchronized”
- Sync contacts and oC birthday calendar to Android device
- Check Android Contact, the Birthday 01.01.1900 can be found there (As well as BDAY:1900-01-01 in the VCARD)
- Check Android Calendar but the Birthday event won’t show up
- Check ownCloud Web-GUI and the Birthday event is showing up
- Sync address book with SOGO Connector in Thunderbird and the Birthday event is showing up
After changing the birthday of the Contact from 01.01.1900 to 01.01.2000 the Birthday event is also showing up in the Android Calendar.
I’m not quite sure if this is an issue in DAVdroid or the Android Calendar itself. If any info is needed please let me know.
@Rancor In a first check, I couldn’t reproduce that behavior with our Android 4.4 test device (Samsung Galaxy Note 10.1) and OwnCloud 9.1.1. The birthday
DTSTART;VALUE=DATE:19001004 DTEND;VALUE=DATE:19001005 RRULE:FREQ=YEARLY
which is correctly synchronized by DAVdroid and visible in the calendar app in Jan 2016. Can you maybe provide the
VEVENTgenerated by OwnCloud? You can find it either using WebDAV or enable verbose logs on DAVdroid, change the birthday in OwnCloud and then synchronize with DAVdroid.
@rfc2822 Sorry for the delay and thanks for the reply. In the meantime i have updated to DAVdroid 22.214.171.124 to make sure that this is not already fixed.
Here are the VCARDS and VCALENDAR entries:
BEGIN:VCARD VERSION:3.0 PRODID:-//Inverse inc.//SOGo Connector 1.0//EN UID:C7423B0A-CCF0-0001-2FE1-4EF0A5A01A78.vcf N:contact;test;;; FN:test contact X-MOZILLA-HTML:FALSE BDAY:1900-10-13 END:VCARD
BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Sabre//Sabre VObject 3.5.0//EN CALSCALE:GREGORIAN BEGIN:VEVENT UID:C7423B0A-CCF0-0001-2FE1-4EF0A5A01A78.vcf DTSTAMP:20161013T052841Z DTSTART;VALUE=DATE:19001013 DTEND;VALUE=DATE:19001014 RRULE:FREQ=YEARLY SUMMARY:test contact's Birthday (1900) TRANSP:TRANSPARENT END:VEVENT END:VCALENDAR
BEGIN:VCARD VERSION:3.0 PRODID:-//Inverse inc.//SOGo Connector 1.0//EN UID:C7423B0A-CCF0-0001-2FE1-4EF0A5A01A78.vcf N:contact;test;;; FN:test contact X-MOZILLA-HTML:FALSE BDAY:2000-10-13 END:VCARD
BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Sabre//Sabre VObject 3.5.0//EN CALSCALE:GREGORIAN BEGIN:VEVENT UID:C7423B0A-CCF0-0001-2FE1-4EF0A5A01A78.vcf DTSTAMP:20161013T053408Z DTSTART;VALUE=DATE:20001013 DTEND;VALUE=DATE:20001014 RRULE:FREQ=YEARLY SUMMARY:test contact's Birthday (2000) TRANSP:TRANSPARENT END:VEVENT END:VCALENDAR
The 1900 Birthday won’t show up in the Androids Calendar. After changing the year to 2000 and syncing again the Birthday Event will show up in Android.
I was also able to pinpoint the year where this is happening. An event of 13.10.1902 is shown in the calendar, anything below like 13.10.1901 won’t show up.
Could it be that this is just a limitation on newer Androids (mine is CM13 / Android 6.0 where yours is Android 4.4)?
@Rancor I could reproduce the problem with CM13. It’s funny
For instance, 1900-02-13 is UNIX time -2205273600 (2205273600 seconds before 1 Jan 1980 00:00 UTC). Because Android stores
dtstartin milliseconds, it’s -2205273600000. When the content provider is passed this value for the
dtstart INTEGERSQLite field, it becomes 2089670400000 (Mar 21 2036 00:00 UTC), probaby because of the overflow of a
intvalue in the provider: 32-bit signed
inthas a range from -2147483648 to +2147483647. If you scroll to Mar 2036, you will see this birthday (note that not only the year is incorrect, but the date is 21 Mar instead of 13 Feb because of the overflow).
However, if you use 1902-02-13, the
dtstartinserted by DAVdroid is -2142201600000 [ms UNIX time]. This is now within the range of
intand will be processed correctly.
Because DAVdroid provides the correct
dtstartvalues to the Android calendar provider and SQLite is perfectly capable of storing up to 8 bytes in
INTEGERvalues, there must be an overflow problem in the Android calendar provider, probably caused by using
longsomewhere. If you want to exactly identify or fix this problem, please work with the Android calendar provider source code. It’s possible that this bug was introduced with Android 5 or 6.
For historical reasons when performing time calculations all arithmetic currently takes place using 32-bit integers. This limits the reliable time range representable from 1902 until 2037.
So, only dates between 1902 and 2037 will be processed correctly and it’s really a 32-bit problem.
To fix the problem, Android calendar provider would just need to use
android.text.format.Time. I have created an Android bug report for this: https://code.google.com/p/android/issues/detail?id=225154
Wow, nice Debugging. Thank you for the detailed insight and the report to the Android bugtracker.
d7415 last edited by d7415
Hi. Sorry to resurrect this, but it’s been bugging me for months and I just found this diagnosis. I see Google in their eternal wisdom closed it as obsolete. Before I reopen, it this still the root cause, or is it likely to be something else 4 years later?
Thanks! And thanks for the app, and for confirming I’m not mad!
( Issue link (moved, old URL works too): https://issuetracker.google.com/issues/37123279 )
Edit to add: I’ve hacked all of my 1900 recurring dates to 1920 which has “fixed” it for the time being. Thank-you!
Before I reopen, it this still the root cause, or is it likely to be something else 4 years later?
I haven’t checked it, but I’m quite sure that they didn’t change anything related to that.
Thanks. That’s all I was after - I figured if they changed anything substantial DAVx⁵ would have had to be changed to match. I’ll see if they’ll pay any more attention now - at least I have a workaround in the meantime.
For reference (until it’s wontfixed): https://issuetracker.google.com/issues/175291071
Marked as fixed (pending release) Thanks again for tracking it down.