[Bug]: Wrong relative time for events in caldav push notifications

[ChristophWurst]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

Since #39862 Nextcloud shows push notifications for events. They do not handle recurrence, so an event always shows relative to the first instance, not the next instance. E.g -1 years

Steps to reproduce

1. Enable notifications app
2. Create a recurring event
3. Have cron running
4. Have an open web session or a connected device

Expected behavior

Notifications shows with correct relative time

Installation method

None

Nextcloud Server version

28

Operating system

None

PHP engine version

None

Web server

None

Database engine version

None

Is this bug present after an update or on a fresh install?

None

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

No response

List of activated Apps

No response

Nextcloud Signing status

No response

Nextcloud Logs

No response

Additional info

No response

[GretaD]

comment from hamza:

\OCA\DAV\CalDAV\Reminder\ReminderService::getVEventByRecurrenceId

I think this method is probably where the problem originates

because it joins the event data from oc_calendar_objects with the oc_calendar_reminder data in \OCA\DAV\CalDAV\Reminder\Backend::getRemindersToProcess which does not do a proper recurrence expansion like the search does if I see that correctly.

apps/dav/lib/CalDAV/CalDavBackend.php:1962 onwards does the expansion for the search

[ChristophWurst]

Observation shows that is is always -1 years, 11months. So it's probably not relative to the first instance of a recurring event but some kind of static value.

[ChristophWurst]

Played with it locally. Events recurring daily and weekly do not cause the bug here. I must be missing something.

SELECT * FROM oc_notifications WHERE user = 'admin' AND app = 'dav' AND subject = 'calendar_reminder'

could help debug the raw data written for notifications

[ChristophWurst]

From an affected instance. It doesn't matter if the event happens once, daily or weekly

[ChristophWurst]

Data looks fine

{
  "title": "Weekly",
  "description": null,
  "location": null,
  "all_day": false,
  "start_atom": "2023-11-22T17:30:00+01:00",
  "start_is_floating": false,
  "start_timezone": "Europe/Vienna",
  "end_atom": "2023-11-22T17:45:00+01:00",
  "end_is_floating": false,
  "end_timezone": "Europe/Vienna",
  "calendar_displayname": "Personal"
}

[ChristophWurst]

It looks very similar to php/php-src#9699

[ChristophWurst]

Bingo!

https://3v4l.org/FG7bP#v8.1.2

vs

https://3v4l.org/FG7bP#v8.1.10

[ChristophWurst]

https://3v4l.org/IQnhj for a combined view

[ChristophWurst]

@AndyScherzinger @jancborchardt what do you suggest for a workaround if more instances on Ubuntu LTS run into this?

Doing date diffing ourself would be a lot of work. As an alternative we could check if the years difference is <0 and then just hide the relative time.

[SystemKeeper]

Could we use the test cases posted above to detect if a faulty PHP version is used and decide with this if we can use relative time or not?

[ChristophWurst]

Good idea!

[AndyScherzinger]

Doing date diffing ourself would be a lot of work.

I agree

As an alternative we could check if the years difference is <0 and then just hide the relative time.

Sounds good to me

Could we use the test cases posted above to detect if a faulty PHP version is used and decide with this if we can use relative time or not?

Also I also like this one as a way to deal with it