OK. Your efforts are appreciated. Thanks. ☺
Recurring events before year 1902 are not shown in calendar
-
Hi,
its hard to search for such specific issues in here so hope this wasn’t reported before.
Setup:
DAVdroid 1.3.1 from F-Droid
Cyanogenmod 13 (latest nightly) with default calendar
ownCloud 9.0.5Steps 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
BDAY:1900-10-04
becomes aVEVENT
withDTSTART;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
VEVENT
generated 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 1.3.2.2 to make sure that this is not already fixed.
Here are the VCARDS and VCALENDAR entries:
Birthday 13.10.1900
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
Birthday 13.10.2000
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
dtstart
in milliseconds, it’s -2205273600000. When the content provider is passed this value for thedtstart INTEGER
SQLite field, it becomes 2089670400000 (Mar 21 2036 00:00 UTC), probaby because of the overflow of aint
value in the provider: 32-bit signedint
has 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
dtstart
inserted by DAVdroid is -2142201600000 [ms UNIX time]. This is now within the range ofint
and will be processed correctly.Because DAVdroid provides the correct
dtstart
values to the Android calendar provider and SQLite is perfectly capable of storing up to 8 bytes inINTEGER
values, there must be an overflow problem in the Android calendar provider, probably caused by usingint
instead oflong
somewhere. 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.Edit: the calendar provider uses
android.text.format.Time
(which is deprecated) to check/fix all-day date/time values. Its documentation states: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
java.util.Calendar
instead ofandroid.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.
-
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!
-
Hi,
@d7415 said in Recurring events before year 1902 are not shown in calendar:
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.