Recurring events not displayed in web UI after January 2038 (Y2038 boundary)

[RodBarnes]

Steps to reproduce

1. Create any recurring event with no end date (e.g., a weekly or annual event)
2. In the Calendar web UI, navigate forward month by month toward early 2038
3. View January 2038 — recurring event instances appear as expected, including in the overflow days from February visible at the bottom of the January monthly grid
4. Click forward to view February 2038 — the calendar is completely empty; no recurring event instances appear

Expected behavior

Recurring events should continue to appear in February 2038 and all subsequent months, as the events have no end date.

Actual behavior

The monthly view for February 2038 and all later months is empty. Recurring events that appear correctly in January 2038 — including in the February overflow days visible within the January grid — are completely absent when February is viewed as its own month.

Calendar app version

6.4.0

CalDAV-clients used

DAVx5

Browser

Brave 1.90.121 (Official Build) (64-bit) Chromium: 148.0.7778.96

Client operating system

Linux Mint 22.3

Server operating system

Debian 13

Web server

None

Database engine version

None

PHP engine version

None

Nextcloud version

32.0.3 (Nextcloud AIO docker container)

Updated from an older installed version or fresh install

None

List of activated apps

Nextcloud configuration

Web server error log

Log file

Browser log

Additional info

When the same calendars are accessed via a CalDAV client (tested with Samsung Calendar on Android), recurring events appear correctly in February 2038 and beyond. This confirms:

• The underlying RRULE data is intact
• The Nextcloud CalDAV server is serving the recurrence data correctly
• The bug is isolated to the web UI's client-side recurrence expansion logic

This indicates the JavaScript recurrence expansion library used by the Calendar frontend is hitting a 32-bit integer boundary for future event instances. This is odd given that most engines today use 64-bit floats for Date objects and are capable of representing dates well beyond 2038.

[SebastianKrupinski]

Hi @RodBarnes

This is a know limitation.

[RodBarnes]

This is a know limitation.

Thank you. I did search but didn't find anything that seemed to match. (I did find one person trying to get dates before the beginning of the epoch 🙂.)

Obviously, there's a lot of time to worry about correcting this. 😁