Datumsfeld bei den Profilen: welche Funktionen gibt es?

wenn du es in purem PHP machen willst/kannst, suchst du vermutlich die Funktion mktime. Die generiert aus einzelnen Angaben den Unix-Timestamp, der das gleiche Schema wie time() benutzt und dann vergleichbar ist.
Konkret würde es für deinen Fall irgendwie so aussehen müssen (hab die Struktur des time-arrays leider net im Kopf, aber sinngemäß):

Weitere Infos zur Benutzung von mktime() gibts unter http://de.php.net/manual/de/function.mktime.php

Viel Erfolg...!

Grüße, phlo

Guckst Du hier: http://www.php.net/mktime

-------------
quiptime

also mktime ist mir durchaus ein Begriff, die Umsetzung währe auch nicht unbedingt das Schwerste.
Mich wundert nur, dass man sich diesen Weg überlegt hat, denn Datenbanktechnisch und für 90% der Scripte ist der Timestamp meiner Ansicht nach der bessere (und gängigere) Weg.
Aber dann werde ich mich wohl dransetzen und die mktime-umschreibung einbasteln.

Bei einem Datum älter als 1.1.1970 funktioniert der Timestamp nicht.

siehe auch http://de.wikipedia.org/wiki/Zeitstempel

Gruss, Ralf

---
Ralf Stamm - drupalcenter

Wo liegt eigentlich Dein Problem?

Verwende doch den Inhalt des Array in der Form YYMMDD. Mit diesem Format kannst Du rechnen bzw. Datum sortieren oder vergleichen.

-------------
quiptime

...wenn er schreibt dass Timestamps gängiger und besser sind, und sie sind auch sicherlich die professionellere Art mit Daten umzugehen, da man durch die Verwendung von Zeitstempeln grade bei gut ausgelasteten Anwendungen massig Rechenzeit spart; man benötigt für Vergleiche und Rechnungen eben nur einen CPU-Taktzyklus gegenüber mehreren bis hin zu vielen wenn man mit Tagen, Monaten und Jahren (und im schlimmsten Fall noch mit Stunden, Minuten und Sekunden) rechnen muss.
Außerdem benötigt man im Regelfall auch in Datenbanken nur ein Feld mit Int Unsigned anstatt mehreren komplexen, was auch Speicherplatz spart und die Datenbank performanter macht.

Der Fairness halber muss man natürlich aber auch sagen dass das Argument des positiven und negativen Überlaufs berechtigt ist, vor dem 1. Jan. 1970 und nach dem 31. Dez 2038 wird es schwierig, ersters ist vor allem bei Geburtstagen relevant, zweiteres wird in Fachkreisen mittlerweile schon mit ähnlicher Intensität wie das Y2K-Problem diskutiert.
Für beide Probleme gibt es jedoch auch Lösungsansätze, ersteres kann durch negative Timestamps (was aber nicht überall unterstützt wird) umgangen werden, zweiteres durch Erweitern des bisherigen 32-bit-Formates auf 64 bit.

Insgesamt betrachtet sind jedoch zum jetztigen Zeitpunkt trotzdem sicherlich Timestamps sinnvoller, und um auf die Ausgangsfrage des OP zurückzukommen, ich meine in Drupal irgendwo schon Timestamps gesehen zu haben...zumindest werden sie im Timestamp-Format in der Datenbank gespeichert, was das User-Objekt angeht...

Grüße, phlo

Ganz informativ die Sache mit der CPU-Last. Das eingetragene Datum ist aber vom Typ date und nicht vom Typ datetime. Also wird schon mal nicht mit Stunden, Minuten und Sekunden gerechnet. Weiterhin muss man ja nicht die vergleichenden Berechnungen mit PHP ausfuehren sondern kann bei vorliegendem Typ date die Berechnungen auch von MySQL ausfuehren lassen. Das duerfte die effektivere Methode hinsichtlich Geschwindigkeit und CPU-Last sein.

Ich denke, das Problem mit der Zeit vor 1970 ist der Grund fuer den Feldtyp date bei Userprofilen. Da wie gesagt MySQL selbst Funktionen fuer die Berechnungen und formatierte Ausgabe von Feldtypen mit date bietet ist der Momentane Zustand eigentlich als effektiv zu bewerten.

Momentan weicht die Disskusion von der eigentlichen Fragestellung etwas ab.
Auf jeden Fall ist zu erkennen das Drupal an dieser Stelle keine fertigen Funktionen bietet die man zu vergleichenden Berechnungen bei Datumsfeldern von Userprofilen verwenden kann.

Beispiel als Ansatzpunkt:

-------------
quiptime

Hi, ja da hast du natürlich ebenfalls recht, im Zweifelsfall ist das DBMS normalerweise schneller was Datumsberechnungen angeht. Nur wenn man eine Variable der Rechnung nur über PHP kriegen kann wirds eben etwas doof, wobei SQL durchaus auch Operationen ohne konkreten DB-Zugriff beherrscht (SELECT 1+1;). Allerdings braucht selbst das DBMS deiner Wahl mehrere Taktzyklen dazu. Aber das steht ja auch nicht zur Debatte, das sind wenn dann Performance-Feintuning-Tips. Nur, was mich wundert (ich bin WebApp-erfahren, aber recht neu bei Drupal) ist dass zumindest in meinen Datenbankschemata alle Zeiten als timestamps auftauchen, nicht als date-Feld. Daher: Reden wir überhaupt von der selben Version?

Ansonsten, um die ursprüngliche Fragestellung wieder aufzugreifen, ich denke wenn wir so weit in die Materie hineingehen wäre es nützlich, genau zu wissen was der OP vorhat...Ich habe beim Einlesen in die API auch keinerlei passende Funktion zu diesem Problem gesehen, selbermachen wird vermutlich auf jeden Fall vonnöten sein, ob nun per SQL oder PHP...

Beste Grüße,

phlo

Noch mal zu dem extra Profilfeld Datum. Da es sich im Zusammenhang mit dem User meist um das Geburtsdatum handeln duerfte und im Jahre 2007 wohl doch noch viele Leute leben die vor 1970 geboren sind macht als Feldtyp ein timestamp wenig Sinn und der Feldtyp date ist absolut angebracht.
Im Gegensatz dazu ist das Datum eines Useraccounts vom Typ timestamp. Ebenso duerften alle anderen Datumsangaben bei Drupal (node created, comment created, node updated, usw.) als timestamp in der DB gespeichert werden da hier keine Zeitwerte vor 1970 zu erwarten sind.

@phlo@drupal.org,
wie Du schon sagst, die API bietet keinerlei Funktionen und selber machen ist angesagt.

Wenn ein PHP Template Theme verwendet wird koennen selbst geschriebene Funktionen am einfachsten in der "template.php" abgelegt werden. Zumal wenn differenzierte HTML-Layouts beim Userprofil realisiert werden und in diesem Zusammenhang ein Template fuer die Anzeige des Userprofil verwendet wird.

-------------
quiptime