Store negative unix epoch dates

[abpai94]

Closes #1343

[ByteHamster]

Thanks for working on this. Are you sure that this really fixes things? To me, it looks like it just adds compatibility with one single second as a start date, namely time=0. One second later already works. Is this really worth it? Shouldn't we then rather work on getting negative times to work?

[abpai94]

I made the following modification as a temporary fix to my Baikal postgres setup. I will close this pull request and create a new one with a more substantial improvement to the getTimestamp() which currently uses the Linux Epoch as the 0th date.

[abpai94]

@ByteHamster I have reopened this issue as I worked on sabre-io/dav#1588 and was able to figure out a fix for the why I couldn't store calendarobjects with dates older than the unix epoch. I have already created a fix for that here sabre-io/dav#1635.

[ByteHamster]

Hmm the original mysql example from sabre/dav only allows non-negative dates. I wonder why. https://github.com/sabre-io/dav/blob/master/examples/sql/mysql.calendars.sql#L10

In any case, your change just adapts the initial database version and does not upgrade users. If we are sure that the change is fine, we should migrate users on upgrade.

[abpai94]

Hmm the original mysql example from sabre/dav only allows non-negative dates. I wonder why. https://github.com/sabre-io/dav/blob/master/examples/sql/mysql.calendars.sql#L10

You make a good point, I seemed to misread UNSIGNED as SIGNED for some reason. I corrected that in the most recent commit.

In any case, your change just adapts the initial database version and does not upgrade users. If we are sure that the change is fine, we should migrate users on upgrade.

With regards to the migration for users to upgrade we can include a migration.sql files which includes something like this:

# MySQL
ALTER TABLE calendarobjects MODIFY COLUMN firstoccurence INT(11) SIGNED;
ALTER TABLE calendarobjects MODIFY COLUMN lastoccurence INT(11) SIGNED;
# Postgres
ALTER TABLE calendarobjects DROP CONSTRAINT calendarobjects_firstoccurence_check;
ALTER TABLE calendarobjects DROP CONSTRAINT calendarobjects_lastoccurence_check;

I can wait on your word about how to proceed with regards to the migration for users to adapt their existing databases.