nextcloud
Can't select dates older than 1 Jan 1970 or newer than 2038
Expected behavior
Select date older than 1 Jan 1970
Actual behavior
Unable to select dates older than 1 Jan 1970
Calendar app version
Any
Hi @Sjoerd001
This is expected behavior we save date and times in the database as an epoch (unsigned integer) which does not support a negative number (any date before 1 Jan 1970)
What is the use case for this? Why do you need to set a date that far back.
The world didnt start at a computer epoch.
There are dates and times in my csv/vcf files that starts before this epoch. I even have notes from 1933. Some people gets older then 55 of age. :)
Source Wikipedia: An epoch or reference epoch is an in time chosen as the origin of a particular calendar era. The "epoch" serves as a reference point from which time is measured.
The moment of epoch is usually decided by congruity, or by following conventions understood from the epoch in question. The epoch moment or date is usually defined from a specific, clear event of change, an epoch event. In a more gradual change, a deciding moment is chosen when the epoch criterion was reached.
Well I can understand the use case, but the solution is not easy.
We use epoch time for efficient searching, the database format currently only supports Unsigned Int (anything greater than zero), so it would require a database migration patch. The other problem is that the UI would need to be adjusted.
This unfortunately is not a easy fix and would require permission from product planning.
Same for 1 Jan 2038. Can't select a later date... Seems you can only select a date in a timespan of 68 years?!
@petrarca-arezzo I'm not sure i understand your reply.
I cant select a date before 2 jan 1970 and cant select date after 1 jan 2038.
PS: Running NC 31 latest stable as of 2025-03-23
Hi.. stumbled accross the same issue for birthday/wedding calendar I'm not sure, if the database is the problem here.
Why i think so? Because it's possible to handle these events before 1970 properly if you manually enter these dates or scroll month-by-month backwards in the calendarcontrol to enter these dates... With recurring events it seems not to be possible to alter these events except you scroll backwards to the first occurance. So i assume it's more a frontend problem...
Hi.. stumbled accross the same issue for birthday/wedding calendar I'm not sure, if the database is the problem here.
Why i think so? Because it's possible to handle these events before 1970 properly if you manually enter these dates or scroll month-by-month backwards in the calendarcontrol to enter these dates... With recurring events it seems not to be possible to alter these events except you scroll backwards to the first occurance. So i assume it's more a frontend problem...
The database will be an issue as the date fields are unsigned int (cannot be negative) and dates before 1970 would be a negative int.
As for the anniversary day dates, I recently fixed this issue, you can now make yearly recurring events based on a specific absolute date (the 16th of April) or relative date (3rd week or April)
https://github.com/nextcloud/calendar/pull/6817
As for the anniversary day dates, I recently fixed this issue, you can now make yearly recurring events based on a specific absolute date (the 16th of April) or relative date (3rd week or April)
it's not exactly what i'm confronted with, but every solved issue is good.. i can't exactly describe what i did, but altering recurring events with a start date before 01.01.1970 led to duplicate calendar entries for me in some cases. Altering these events was only reliable possible, if i altered the original events by scrolling back to the year/month of occurance....
It's not a big deal for me because there are only a few dates affected. Once entered, i will never touch them again (probably) But if there is a datetime-field, where a user can enter a date, he should be able to enter any kind of date. Otherwise there should be a plausibility check before saving it to database and leading to inconsitency.
Best D
I suggest migrating to TAI64. It would solve all conceivable date and time problems, as far as I can see. There is a PHP library for it: https://packagist.org/packages/amaccis/datetai
The package page has links to a C library, and a link to this article, describing the format:
Background: https://en.wikipedia.org/wiki/International_Atomic_Time
(probably) But if there is a datetime-field, where a user can enter a date, he should be able to enter any kind of date. Otherwise there should be a plausibility check before saving it to database and leading to inconsitency.
I entered an invalid date on my phone's contacts app (a birthday before 1970), and the result was that the synchronisation with the server stopped. So it's potentially more than just a nuisance.
Hi @muellert
We don't need to migrate to a different time format, We need to adjust our database structure to a SIGNED LONG/WIDE INT, at the moment the field is a Unsigned INT which mean numbers 0+. This migration sounds like a minor step, but has large implications and needs to be tested properly, it will be addressed soon.