vlibDate erzeugt PHP Fehlermeldung und formatiert das Datum nicht korrekt

[indie-ecke]

Einen wunderschönen guten Tag,

bisher hatte ich keine Probleme mit der wunderbaren Template Engine und dem nützlichen Mailer, aber nun,
da ich auch die funktionen der vlibDate für mich erschließen wollte, bin ich zum ersten mal auf ein Problem gestoßen, welches ich nicht lösen kann.

Und zwar zeigt mir der Browser eine formschöne PHP Fehlermeldung oberhalb meines Contents:

Fehlermeldung:

Code: [Select]

Warning: array_values() [function.array-values]: The argument should be an array in /_system_/_class/vlibDate.php on line 105
Warning: array_values() [function.array-values]: The argument should be an array in /_system_/_class/vlibDate.php on line 226
Warning: array_values() [function.array-values]: The argument should be an array in /_system_/_class/vlibDate.php on line 105
Warning: array_values() [function.array-values]: The argument should be an array in /_system_/_class/vlibDate.php on line 226
Warning: array_values() [function.array-values]: The argument should be an array in /_system_/_class/vlibDate.php on line 105
Warning: array_values() [function.array-values]: The argument should be an array in /_system_/_class/vlibDate.php on line 226
Um eventuelle Hillfsversuche zu erleichtern, hier die betroffenen Zeilen der vlibDate.php:

Zeile 104/105:

Code: [Select]

function formatDate ($timestamp, $format) {
  list ($day, $month, $year) = array_values($this->_breakTimestamp($timestamp));
Zeile 225/226:

Code: [Select]

function getWeekdayFullname ($timestamp) {
  list ($day, $month, $year) = array_values($this->_breakTimestamp($timestamp));
Da aber das gleiche Problem bei allen format-funktionen auftritt, ist der code schnipsel zu 225/226 eigentlich irrelevant.

Zudem formatiert er zwar das Datum, jedoch zeigt er nur ds aktuelle an. (soweit mir die dokumentation verriet, zeigt vlibDate ja immer das aktuelle Datum an, wenn ein Fehler auftritt und die Datumsvariable nicht richtig formatiert werden kann...)

Was ich mir vorstellen könnte, denn es ist das einzige was bei mir von der Dokumentation abweicht, ist, dass ich das unformatierte Datum als Timestamp aus einer MYSQL Datenbank hole!
Könnte es vielleicht daran liegen?

Für Hilfe/Anregungen jeglicher Art, wäre ich sehr dankbar.

[ClausVB]

Unformatiert darf bei vlibDate gar nichts sein, so wie es auch in der Doku drin steht:

1) Throughout the documentation you will come across quite often the String type timestamp.
This is not a unix timestamp but a vlibDate timestamp. vlibDate timestamps are simply a string in YYYY-MM-DD format, i.e. 2002-01-25. If a unix timestamp is required the unixtime will be used as the type definition.

Der Timestamp oder was auch immer muss mit verschiedenen Möglichkeiten, wie zum Beispiel DATE_FORMAT(), in

2003-12-31 oder 2007-03-28

umgewandelt werden. Nur dann kann vlibDate funktionieren. Minuten und Sekunden (Unix-Timestamp), etc. werden nicht unterstützt.

Gruß
Claus

[indie-ecke]

Alles klar.
Vilen Dank für die sehr, sehr rasche antwort.
ich werde es sofort einmal testen.

Wahrscheinlich hätte ich mir die antwort auch selbst geben können, hätte ich den Timestamp Topic http://dasprovisorium.de/forum/index.php?showtopic=5761
mal vorher gelesen

Dann wünsche ich noch nen schönen tag soweit.

[ClausVB]

Ich zitere den gemachten (provisorium)Post hier noch einmal und werde noch ein paar Beispiele aus der Praxis geben.

Ich speichere sie grundsätzlich als UNIX-Timestamp in einen INT(11) Feld. MySQL hat auch umfangreiche Datumsfunktionen, aber das läuft dann meistens auf hin und her konvertieren hinaus und ist meiner Einschätzung nach in den meisten Fällen langsamer und etwas umständlicher.

Sorry, ich halte von dem Vorschlag überhaupt nix. Natürlich bleiben Unix-Timestamps bis 2029 (?) gültig, aber gerade weil so eine Mentalität herrscht hatten wir damals das Jahr 2000 Problem.

Hätten unsere COBOL-Programmierer ab 1990 damit angefangen ein Datum nicht mit "31.01.90" abzuspeichern, wäre der Year2K-Umstieg (bei uns) nicht so schwierig geworden.

Außerdem ist der MySQL-DATETIME zu allen Berechnungen in der Lage und er wird in der DB im klar und deutlich ausgegeben.

Unix-Timestamp: 1083433137
DATETIME: 2005-03-01 08:25:12

Welches Format ist sprechender?

Mit Daten rechnen:

Code: [Select]

SELECT MAX(c_open) + INTERVAL 10 SECOND AS open_floodcontrol FROM cases WHERE c_u_id = 105
Das Format 2005-03-01 in ein deutsches (englisches, französisches, etc.) umwandeln mit vlibDate:

Code: [Select]

<?php echo $date->formatDate($row[birthday], %A, %d.%m.%Y); ?>
oder (ohne vlibDate) mit dieser kurzen Programmbeispiel:

Code: [Select]

<?php
// setzt die deutsche Umgebung
setlocale(LC_ALL, "german");

// das Datum muss für den Befehl "strftime" in einen Timestamp
// umgewandelt werden
$datum_unix_timestamp = strtotime($db_date);
$formatiertes_datum = strftime(
"%a, %d. %b %Y",
$datum_unix_timestamp
);
?>
Warum auf etwas "veraltetes" setzen, wenn die Alternative so einfach ist?

Gruß
Claus

PS: Mit den vlibDate Methoden lassen sich auch problemlos Daten subtrahieren oder addieren:

Code: [Select]

<?php echo $futuredate = $date>addInterval($date->now(), 2 CENTURIES 5 YEARS 2 MONTHS 3 DAYS); ?>
Das nur als Anmerkung.


Wir gehen in allen Fällen von Problemstellungen aus, die einen LOOP betreffen.

Problem 1: Es liegt in der Datenbank nur ein Unix-Timestamp, der auch mit Stunden, Minuten und Sekunden ausgegeben werden soll. Der Sonntag soll in der Tabelle immer farbig hinterlegt sein.
Das SQL liefert sowohl den formatierten Timestamp zurück, als auch die boolsche Variable (in diesem Fall 1 oder 0). Da SQL die Arbeit übernimmt, kann man problemlos die Methode "setdbloop" verwenden.

Problem 2: Ein Spalte "DATE" soll als deutsches Datum ausgegeben werden.
Das Beispiel zeigt einen Zugriff auf die Datenbank und die Umwandlung mit vlibDate. Die Daten werden mit einem LOOP-Array aufbereitet.

[indie-ecke]

So, ich hatte es zwar durch die umrechnung recht schnell zum laufen bekommen,
allerdings hat mich die forumsdiskussion dazu bewogen, meine db felder in DATETIME abzuändern.

TIMESTAMP hatte ich nur genommen, weil mein Professor für Datenbanktechnik drauf schwört.
Er meint übrigens, das es zu keinem neuen "Y2K" Problem kommen wird, da in 20 Jahren eh keiner mehr
diese db technik anwendet.
Finde ich persönlich etwas kurzsichtig, er hätte uns zumindest mal drauf hinweisen können.

[ClausVB]

Cobol wurde seit 1985 nicht mehr weiterentwickelt. Ein Server der 197x hergestellt wurde, ließ bis ins Jahr 2004 am Düsseldorfer Hbf die Beschilderung an den Gleisen "klappern". Nicht nur die COBOL-Programmierung musste bis ins Jahr 2004 gewartet werden, als ein Hardware-Teil ausfiel, dass nicht repariert oder ersetzt werden konnte, lief in punkto Beschilderung im HBF nichts mehr.

Soviel zu "läuft" sowieso in 20 Jahren nicht mehr.

Bei uns in der Firma laufen COBOL-Programme immer noch. Die Y2K-Umstellung war ein Riesenaufwand. Mit vlibDate bist Du sicher bis ins Jahr 9999. 7000 Jahre hast Du also noch .

Neue Techniken zu benutzen und veraltete oder fehlerhafte Routinen aus der Programmierung zu entfernen gehört zur Programmierung. Kontinuierlich und fortschreitend, wie es Extreme Programming und Refactoring vorschreiben.

Gruß
Claus