Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] Timestamp Problem bei PHP-Script über Cronjob

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • [Erledigt] Timestamp Problem bei PHP-Script über Cronjob

    Hallo,

    ich habe bezüglich meines Problems leider nichts in diesem Forum gefunden, sollte ich einen Thread übersehen haben oder im falschen Forum gepostet haben, seid bitte gnädig mit mir und schließt/verschiebt diesen Thread.

    Das eingesetzte System:
    Ubuntu 8.10 Server
    Kernel: 2.6.27-11-server
    PHP Version 5.2.6-2ubuntu4.6 (CLI)
    Der Server ist eine VM in einer ESX-Umgebung.

    Zu meinem Problem:
    Ich lasse ein PHP-Script per Cronjob zu bestimmten Zeiten ausführen. Dieses Script speichert u.a. Timestamps in eine MysQL-DB. Wird dieses Script über den User root direkt auf der Console ausgeführt, werden die korrekten Timestamps gespeichert. Führt allerdings der Cronjob dieses Script aus, so liegen alle Timestamps im Jahre 2019.

    Die Funktionsweise der Timestampverarbeitung:
    Das Script holt sich mittels der OCI-Methoden diverse Daten aus einer Oracle-DB, darunter auch ein Datum das im Format "16.06.10" ausgelesen wird. Dieses Datum wird dann in einen Timestamp umgewandelt und gespeichert:

    PHP-Code:
    // getFirstCall gibt ein Datum im format 16.06.10 oder null (falls kein Datum vorhanden) zurück
    $fc_array explode'.'getFirstCall$ora$customer[1] ) );
    if( !empty( 
    $fc_array[0] ) ) {
        
    $first_call mktime000intval($fc_array[1]), intval($fc_array[0]), intval"20" $fc_array[2]) );
    } else {
        
    $first_call 0;

    Eigentlich eine ganz simple und sichere Sache, wenn eben nicht diese massive Zeitverschiebung bei der Cronjob Ausführung wär.

    Der Cronjob is wie folgt angelegt:
    Code:
    01 00 * * *     php /var/www/xxx/scripts/tr_mapper.php >> /var/www/xxx/logs/tr_mapper.log
    01 12 * * *     php /var/www/xxx/scripts/tr_mapper.php >> /var/www/xxx/logs/tr_mapper.log
    01 17 * * *     php /var/www/xxx/scripts/tr_mapper.php >> /var/www/xxx/logs/tr_mapper.log
    Er wird auch ohne Problem mit dem richtigen User ausgeführt:
    Code:
    Jun 16 00:01:01 XXX /USR/SBIN/CRON[23206]: (root) CMD (php /var/www/xxx/scripts/tr_mapper.php >> /var/www/xxx/logs/tr_mapper.log)
    Die Umgebungsvariablen sind auch korrekt gesetzt. Das Script funktioniert ja auch tadellos wenn man es per Hand ausführt.

    So jetzt zu meiner Frage:
    Woran könnte es liegen, dass die Timestamp Umwandlung korrekt ist, wenn das Script über die Console per Hand ausgeführt wird, doch wenn es über einen Cronjob ausgeführt wird, nicht mehr?

  • #2
    Hab nun endlich das Problem gefunden. Es war das Datumsformat der aktuellen Oracle Session. Wenn ich das Script per Hand ausführe ist nls_date_format auf 'dd.mm.yy' gesetzt. Führt allerdings der Cronjob das Script aus, ist das dateformat auf 'dd.month.yy' gesetzt. Warum, wieso und weshalb weiß ich leider noch nicht.
    Habe aber bei der connect-Funktion einfach folgendes mit eingebaut:

    PHP-Code:
    function connectDB$host$user$pass$name ) {
        
    $ora_conn oci_connect$user$pass"//" $host "/" $name );
        if( !
    $ora_conn ) {
            
    $ora_conn_errno oci_error();
            
    oci_close$ora_conn );
            die (
    "Schwerwiegender Fehler beim Verbinden zur Datenbank!\n" $ora_conn_errno['message'] . "\n");
        }
        
    // !!!! session dateformat setzen !!!!
        
    $stmt oci_parse$ora_conn"alter session set nls_date_format = 'dd.mm.yy'" );                         
        
    oci_execute$stmtOCI_DEFAULT );
        return 
    $ora_conn;

    Und um ganz sicher zu gehen habe ich noch im SQL-Satement ein TO_DATE eingebaut:

    Code:
    SELECT TO_DATE( MAX(FIRST_CALL), 'DD.MM.YY' ) AS FIRST_CALL FROM DIENST WHERE ORG_ID='23941' AND PRODUKT_TYP_ID=7
    Der Thread kann somit als erledigt markiert werden

    Kommentar

    Lädt...
    X