Hi. If I set a periodic event (say weekly, for instance) to start on the 16th of december 1969, without specifying any end (no UNTIL or COUNT), I get an alarm each week but only until 11 the 25th 2012, not any further. If I move the beginning field (DTSTART) back and forth, I can see the last occurrence moving back and forth as well. As if there was a maximum time since first occurrence after which the event expires. I would expect the event to occur every week until the Big Crunch. Am I wrong ? Typical example : a birthday. If I set a yearly event for a birthday, specifying a start date before 1970 or 1969 (I use birth date as start date), then I don't get any event/reminder. Version 4.8.3 (debian wheezy)
Very interesting. There is not explicit limits as you suspect. But it is possible that some counter overflows.... There is limit on both the early and late date in Orage. But that is due to linux not being able to handle all dates. (man strftime: The number of seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC).) But you seem to reach a limit much earlier. I was not able to reproduce the issue before date in 2035. I am using also Debian. But I seem to be in 6.0.6, which I think is squeeze. Wheezy is the next version 7.0. Need to check on Monday if I have that in my other test systems. In the mean time, please paste results from: $ orage -v as this may be another libical bug, so it is important to know if you use internal or debian libical. I have: $ LANG=C orage -v This is orage version 4.8.3.2-git Released under the terms of the GNU General Public License. Compiled against GTK+-2.20.1, using GTK+-2.20.1. Using DBUS for import. Using libnotify. Using automatic archiving. Using operating system package libical.
Hi. I also suspect a counter overflow. I tried to check if the maximal number of seconds is close to a power of two, but having zero knowledge of the code, I'm shooting in the dark, here. LANG=C orage -v This is orage version 4.8.3 Released under the terms of the GNU General Public License. Compiled against GTK+-2.24.10, using GTK+-2.24.10. Not using DBUS. Import works only partially. Using libnotify. Using automatic archiving. Using operating system package libical.
Tested this will Wheezy: $ cat /etc/os-release PRETTY_NAME="Debian GNU/Linux wheezy/sid" NAME="Debian GNU/Linux" ID=debian It seems that the problem is indeed dates before 01.01.1970. There are strange behaviours if start date is earlier than the linux epoch. I can not reproduce issues if start date is after 01.01.1970. Can you? I even tried daily repeat and that seems to work after 1970. I think I need to add limitation to not accepts dates before 1970....unless you can reproduce the problem with later dates?
Hi. Well, indeed, I don't reproduce the issue with dates after 1-1-1970. Now, when entering daily events with start dates in december 1969, I get interesting results : 1/12/1969 -> 1 event a month at what looks like random dates, beginning with today n/12/1969 -> n events per month I let you figure that out. > I think I need to add limitation to not accepts dates before 1970 That would be a workaround, at best. Preventing the user from entering an event with a start date before 1970 wouldn't be such an issue, but what about external .ics files ? A start date before 1970 can be legitimate. Just my opinion, I'm not the one doing the job. Thanks for investigating, anyway.
Changed title. This seems to work with the internal libical.
So should we file a bug against debian's libical package ?
Yes, that would be good start. I failed to find the source, so I could not check in more details where it fails, but icalcomponent_foreach_recurrence does not work with older than 1970 dates correctly. **** My local version just skips earlier dates, so it can report those properly, but it can report all later than 1970 dates fine. And Orage very seldom needs to show older dates in calendar, so it basically works. Note to self: - works with internl libical - archiving fixes this also with external (as date then moves to fresh enough time) - dates are always wrong in appointment mod screen (as it undoes archiving) - alarms seem to work correct always - it could possile be worked around by moving year to safe area before processing (uggly hack, but the bug is in libical...)
I believe the source files are those of upstream version 0.48 http://sourceforge.net/projects/freeassociation/files/libical/libical-0.48/ modified by the patches in the source package http://packages.debian.org/source/wheezy/libical Are you saying that it works on your setup with internal libical but not for dates before 1970 ? My use case is the following: Another program (namely gbirthday) has a database of birth dates (this includes birth year) and generates alarms for birthdays. It can export as iCal, setting an alarm that Orage can execute. By default, the start date of the event is the birth date. And the periodicity is one year, obviously. I could workaround this in the iCal export by setting start date as any arbitrary year after 1970. Not nice, but I suppose it would be functional.
Orage internal libical works fine. The only issue it has is that (due to how libical works) it can not show data before 1970. But it just skips over it. So if you have birthday for example 10.9.1908, and you run it today. Orage will show alarms correctly and Orage will show the main calendar correctly. But if you go to year 1969 or older in the main calendar, the appointment vanishes since Orage can't work with earlier dates. But all years after 1970 show it properly in the calendar. And yes, your WA should work even with operating system libical linked in Orage.
OK thanks for making that clear. Hopefully, the diff between internal version and [upstream + debian patches] version should tell us more about what goes wrong in debian's version.
4.9.9.2 has now fix. I tried to find the issue from the new libical source, but there are massive changes compared to the old version Orage uses internally and my first guesses were wrong. So I just changed the code so that it does not run into this issue. Basically I replaced one call to icalcomponent_foreach_recurrence with a manual loop and patched the other call to always use later than 1970 dates. Seems to work now. Hopefully the new 1.0 version libical works fine, but I had no time to test it.
Great job ! Thanks.
Fixed in 4.10.0