#1588: Allow negative linux epoch

[abpai94]

Closes #1588

[abpai94]

Possibly a bit overkill to verify that firstOccurence and lastOccurence are consecutive considering as 64 bit INT timestamps will roll-over in the year 2262. But if there are still people running 32 bit systems in 2038 maybe it will come in handy.

[ralflang]

Possibly a bit overkill to verify that firstOccurence and lastOccurence are consecutive considering as 64 bit INT timestamps will roll-over in the year 2262. But if there are still people running 32 bit systems in 2038 maybe it will come in handy.

I feel different about this. People may very well use their calendaring/event system to model zany things such as the repetition of easter or moon phases or anniversaries of battles because it contains all the complicated date math already - and exposing them to caldav/carddav may be an unintended but welcome side effect. Being defensive about dates outside our narrow PIM horizon isn't overkill, it's prudent.

[abpai94]

@ralflang yes you make a good point, we should cover the edge cases and throw an error if we ever end up rolling over to prevent dates getting wrongly added to the calendar.

However I used https://www.epochconverter.com/ to calculate the 64 bit date (year 2262) and I think the website didn't provide the right answer if I understood correctly. But I'm still working on verifying this before pushing for a fix.

[abpai94]

@ralflang as a heads up you may want to checkout the following issues which is also related sabre-io/Baikal#1344 where I have proposed some changes to the MySQL and Postgres database schemas. If you are using either of them you should apply the patch I have proposed.