Event dates prior to 1970

[Anke]

I need to create a chronicle as an eventlist with future dates as well as events dating dack to the 50's. However in events all dates are resetted to 1970.

Is there a solution for this and possibly a workaround for the time being?

Dates prior to 1970 are also needed i.e. in FE birthday calendars.

[tristanlins]

In theory: yes Timestamps can be negative to indicate a date prior 01.01.1970.

$ php -r 'echo mktime(0, 0, 0, 1, 1, 1950);'
-631155600
$ php -r 'echo strtotime("1950-01-01");'
-631155600

The issue is simply explained: The news date and time fields does not allow negative values: https://github.com/contao/core/blob/master/system/modules/news/dca/tl_news.php#L223

Put this into your system/config/dcaconfig.php, do a database update and try again:

$GLOBALS['TL_DCA']['tl_news']['fields']['date']['sql'] = "int(10) NOT NULL default '0'";

[Anke]

Thank you for your help Tristan. Sorry to say, but I get a '=>' (T_DOUBLE_ARROW) message. And I need it for calendar events, so I guess this is the line I need to change:

$GLOBALS['TL_DCA']['tl_calendar_events']['fields']['startDate']['sql'] => "int(10) unsigned NULL";

Would you let me know what to change here?

[tristanlins]

Ooops, copy and paste fail ^^ it must be:

$GLOBALS['TL_DCA']['tl_news']['fields']['date']['sql'] = "int(10) NOT NULL default '0'";

[Anke]

Hiermit wird das Datum korrekt in die DB geschrieben: $GLOBALS['TL_DCA']['tl_calendar_events']['fields']['startDate']['sql'] = "int(10) NULL";

Aber die Ausgabe in FE und BE lautet immer noch 1.1.1970. Kann ich da auch noch was machen?

[Anke]

Okay, ich lasse das Datum im FE-Template der Eventliste parsen, Damit wir das Datum richtig angezeigt, aber die Sortierung stimmt jetzt bei den Daten vor 1970 nicht. Und im BE im Eventarchiv steht noch überall 1.1.1970.

Was spricht denn dagegen, Events und News standardmäßig auch Daten vor 1970 verarbeiten zu lassen, um historische Ereignisse aufnehmen zu können?

[aschempp]

Durch die Zulassung von negativen Zahlen wird die Menge an möglichen positiven Zahlen reduziert. Entsprechend kannst du News dann nur noch bis 2038 statt bisher bis 2106 datieren.

http://en.m.wikipedia.org/wiki/Year_2038_problem

Es liesse sich aber wohl darüber diskutieren ob ein Datum in weiter Ferne für News so viel Sinn macht...=

[Anke]

Okay, ich verstehe da nicht viel von, aber wenn das ein lange bekanntes Apache-Problem ist, hätte ich angenommen, dass schlaue Programmierer Lösungen für dieses Problem gefunden hätten ... ;-)

Wie ich gesehen habe, sind im Forum sind noch einige Anfragen zu finden, wo historische Ereignisse (z.B. ab 1024) verwaltet werden sollten. Aber wenn ich euch richtig verstehe, ist es tatsächlich so, dass weder das News-Modul noch Calendar/Events zuverlässig genutzt werden können, um größere Datumsbereiche zu nutzen?

[Samson1964]

Jahr 1024? Okay, soweit wollte ich nicht zurück. Aber 16. Jahrhundert käme bei mir schon in Frage. Irgendwo im Forum hatte ich auch geschrieben, daß nach einer Änderung des Datentyps immerhin irgendwas bis 1906 möglich war. Aber leider nicht davor.

Wenn ich mich mal wieder mit historischen Sachen beschäftige, werde ich wahrscheinlich nicht umhin kommen, ein eigenes Modul zu schreiben, wo ich nicht mit dem Unix-Zeitstempel arbeiten muß.

[discordier]

See my (related) comment on: https://github.com/contao/core/issues/7364#issuecomment-60336876

[Aybee]

I think this is a bug not a feature. If the "Date format" in settings is e.g. "d.m.y" you can not save birthdays before 01.01.1970. "d.m.Y" works fine. Also the datepicker interprets e.g. 31.01.70 (d.m.y) as m.d.y and thus can not find a date.

New ticket is here https://github.com/contao/core/issues/8593

[discordier]

This is then a problem of the date picker only and has to get solved in the picker javascript. It does not apply to the issue discussed here which is about the limitation of 32bit timestamps. If it would apply, switching to d.m.Y would not solve the problem at all.

[Aybee]

Ah, ok. Ich dachte Ticket #8509 wäre das richtige und das war als duplicate von diesem hier ausgezeichnet und geschlossen. Wenn das jetzt doch was eigenes ist, dann müsste ich wohl ein neues Ticket aufmachen, oder kann man ein neues Ticket daraus erstellen?

[discordier]

The mentioned ticket is indeed a dupe of this one in respect of discussing the limitation of 32bit integers.

It has however nothing to do with the date picker javascript and therefore you should open a new ticket for that one describing exactly that this is only an issue with the picker and your findings with the different behaviors with the various date formats.

[Aybee]

Done https://github.com/contao/core/issues/8593

[ghost]

Don't get the overall solution with this issue. Can anyone please explain it a little more in detail.

Using

$GLOBALS['TL_DCA']['tl_calendar_events']['fields']['startDate']['sql'] = "int(10) NULL";

stores the dates correctly in the dabase but it's still shown wrong in the backend and recurrences are generally not visible in the frontend. So there must be more required than changing db design only.