[gelöst] Date als GebDatum geht nicht älter als 39 Jahre?

Das hängt wohl damit zusammen. Versuch doch einfach mal das Datum nicht im Dimestamp-Format zu speichern (Einstellungen CCK-Feld). und dann in einem anderen Format zu rechnen.

Also ich habe drei verschiedene CCK Feldtypen
Datum
Datestamp
Datetime

egal welches ich nutze, ein Datum älter als 1970 wird erst gar nicht in der DB gespeichert. Da läuft sich einfach nur das Skript tot. Es kommt also gar nicht erst zu der Berechnung durch ein Computed Feld. Habe ich noch einen Denkfehler?

Ich habe jetzt sowohl hier als auch auf Drupal.org geposted.

Irgendwie kommt es mir so vor, als wenn ich der erste wäre, bei dem dieses Problem auftaucht oder es hat sich noch nie jemand Gedanken gemacht, dass Community Mitglieder auch durchaus vor dem 1.1.1970 geboren worden sein könnten.

Hat noch nie jemand dieses Problem gelöst?

Du bist nicht der erste, der sich mit dem Problem herumschlägt. Seit ich aber einige Zusatzmodule installiert habe, klappts. Tatsächlich verwende ich nun ein DateTime für ein Geburtsdatum in CCK.

Module:
Date
Date API
Date PHP4 (kommt auf die verwendete PHP-Version an)
Date Popup
Date TimeZone

Ausserdem nutze ich für Datumsberechnungen in meinen eigenen Modulen die adodb-time.inc.php.

Ich kann mich auf den Kopf stellen

Ich habe all diese Module (2.4) installiert. Ich habe Date, Datetime, Timestamp... alles ausprobiert. In dem Moment, wo ich ein Datum vor dem 1.1.1970 speichern will, rennt es sich tot.
Ich nutze eine PHP 5.1* Version.

Das kanns doch wirklich nicht sein. Seit 4 Tagen doktor ich an dem Mist rum, so langsam macht es mich sauer......
Es kann doch nicht so schwer sein, zumal das Date Format als varchar in der Datenbank abgelegt wird. Das Problem muss doch also irgendwo seitens des Date Modul liegen. Irgendwo passt doch irgeneine validierung nicht.

Dennis

"Mein" DateTime-CCK Feld wird als datetime im mysql gespeichert!!

Meine MySql-DB ist local, Server und Client Version 5.1.30, Apache/2.2.11 (Win32) DAV/2 mod_ssl/2.2.11 OpenSSL/0.9.8i mod_autoindex_color PHP/5.2.8

Was vielleicht noch ein Hinweis ist: Die Date-Zusatzmodule sind in einem Unterordner von Date anzusiedeln. Habe auch die 2.4-Versionen.
Vielleicht fehlt ein update.php-Lauf?
Kontrolliere auch die Datum und Zeit-Einstellungen, ev. nochmals speichern.
Cache leeren. Und dann schau mal, was mit einem neuen CCK-Feld für das Datum geschieht.

Also

bei mir sieht die Konfig so aus:

Mysql 5.0.18 local, Apache 2.2.3 (Linux) PHP 5.1.2

Ich habe jetzt nochmal ein paar andere Datumsfelder angelegt. Auch mal die anderen Typen probiert. Es tut sich nichts. Auch update.php, cache leeren alles ohne Erfolg. Aus Verzweiflung habe ich mal auf die Date dev Version aktualisiert. Kein Erfolg.

Ich muss ja schon davon ausgehen, dass das ganze irgendwo damit zusammenhängt, dass irgendwo in dem Modul versucht wird, selbst ein als Date (varchar in der DB) deklariertes Feld durch eine Routine geschickt wird, die das ganze doch wieder in einen Unix Timestamp umwandelt, oder es zumindest versucht. Da ich PHP 5.1.2 nutze, kann es doch eigentlich nur in dem PHP4 Modul hängen.

Es nervt einfach nur noch.

Noch etwas interessantes:

Wenn ich direkt in die Datenbank gehe und spaßeshalber mal das Datum auf einen Wert vor dem 1.1.1970 setze, also von Hand, interessiert es das das Frontend überhaupt nicht. Es wird pauschalt das alte Datum ausgegeben. Wie kann das denn sein? Cached er die Ausgabe noch irgendwo in der DB und liegt vielleicht dort der Hund begraben?

Also das gar nicht das Datemodul scheisse baut sondern irgendwo ein Cachemechanismus, der die Feldeingaben auch nochmal zwischenspeicher?

Dennis

Eine Suche ergab,

tatsächlich, es wird in der Tabelle cache_content auch gespeichert. Liegt es daran? Wie kann ich diesen Cachemechanismus aussetzen lassen?

Dieser Cache-Mechanismus ist mir jetzt unbekannt...was mich aber immer noch vielmehr erstaunt ist, dass Du in der DB das Datums-Feld in einem Varchar hast, während bei es bei mir ein Datetime ist!?!
Hast Du denn ausprobiert, was passiert, wenn Du ein GANZ NEUES DateTime-CCK-Feld machst, vielleicht testweise sogar mal in einem neuen Inhaltstyp?

Ja habe ich. Es passiert immer das selbe.

Aber jetzt halt dich fest ich habe weiter gesucht.
Ein Blick in die Errorlogs des Servers zeigen, dass jedesmal, wenn ich versuche ein Datum vor dem 1.1.1970 zu speichern, in der Datei

httpdocs/sites/all/modules/date/date_php4/date_php4.inc on line 736

die maximale Ausführungszeit von 120 Sekunden überschritten wird. Und als wenn ich es geahnt hätte, passiert das folgende in der Zeile:

strtotime ist ja nunmal eine typische Unixtimestamp Geschichte. Das heisst, egal was ich versuche, an dieser Stelle wird immer versucht, mit einem Epochenzeitstempel zu arbeiten. Was bei einem Date in einem negativen Wert enden würde oder eben gar nicht. Muss ich nun die Datei hacken und mir etwas anderes für diesen Fall einfallen lassen?

Ei, schau mal, was ein paar Zeilen weiter oben drin steht:

Jetzt würde ich wohl das Modul Date PHP4 deaktivieren...

Tja,

und wenn ich das mache, rennt die gesamte Seite anschließend überall, wo auf mein Datumsfeld zugegriffen wird in eine weisse Seite.

Und nun?

Hallo.
Wenn Du eine weisse Seite bekommst, solltest Du in Dein error-log von PHP schauen. Dort siehst Du dann, welche Fehler die weisse Seite verursachen.

 Stefan

Oh je, jetzt gehen mir die Ideen auch aus...

Wahrscheinlich würde ich jetzt an dem Punkt eine parallele Drupalinstallation aufziehen und gucken, obs dann damit geht. Dann wüsste ich, ob Drupal verhunzt ist, oder ob es ev. am Webserver/PHP liegt.
Ich hoffe, dass sich noch andere hier einklinken

Brauch ich gar nicht, kann ich mir ja so denken:
Ich habe PHP 5.1.2 installiert, also versucht die Dateapi ums Biegen und Brechen auf das PHP 4 Modul zuzugreifen. Das das aber scheinbar verbuggt ist, kann ich nicht mit und auch nicht ohne.

Das Projekt ist nur leider so dermaßen weit vorangeschritten, dass ein Umzug aktuell nicht in Frage kommt, also ein Umzug auf einen Server mit php 5.2.*
Da muss es doch wirklich eine Lösung geben. Wozu haben die sonst dieses Modul da hingeschmissen?

Grummel

So, scheinbar kurz vor dem Ziel:

ich habe alles andere jetzt ausgeschlossen und die Funktion, die den Fehler macht extrahiert

year >= 1970, es ist alles in Ordnung. year < 1970 rennt sich der Bereich tot. Nun ist die Frage, woran genau liegt es, weil strtotime ohne die Übergabe dieser Parameter mit einem Datum < 1970 wunderbar funktioniert.

Es ist auch nicht der part strtotime("last sunday UTC") oder der part strtotime("1 april $year UTC") alleine. Die Kombination macht es. Ich denke, dass man strtotime als zweites Argument keinen negativen Wert übergeben kann, den negativ wird der zweite strtotime Ausdruck, wenn eine Jahreszahl vor 1970 übergeben wird.

Kurzes Zitat von strtotime:

Etwas weiter unten heisst es aber:

Naja, offensichtlich kommt Dein System mit den negativen Werten nicht klar.
Aber Du möchtest ja nicht ins Error-log schauen um dem Fehler eventuell auf die Spur zu kommen ...

PHP Error Log: Nichts neues

[11-Jun-2010 14:21:43] PHP Fatal error:  Maximum execution time of 120 seconds exceeded in

Ich habe jetzt einfach in der
date_php4.inc
Zeile 616 die variable $regions auf 0 gesetzt, so dass es zu keiner Arbeit dieser Funktion kommt. Es scheint alles zu funktionieren danach.

Es ist nur eine vorläufige Maßnahme und zur Nachahmung nicht empfohlen, da völlig ungewiss ist, welche Auswirkungen das ganze sonst noch hat.