Versuchen Sie, Ihre php.ini-conf zu überprüfen und Ihre Zeitzone einzustellen.

Zeitzone in meiner php.ini ist korrekt

Danke & Grüße
Lijo Joseph George
Technisches Team|| ManoramaOnline
Handy: +91 9895336448 | Büro : +91 0481 2563646 | Ext :670
Besuchen Sie uns: www.manoramaonline.com | LinkedIn | Facebook | Twitter

Von: iHunt NSA [email protected]
An: osTicket/osTicket [email protected]
Cc: lijo joseph george [email protected] , Autor
[email protected]
Datum: 06-02-2017 AM 09:19
Betreff: Re: [osTicket/osTicket] Ticketzeit wird falsch angezeigt
(#3654)

Versuchen Sie, Ihre php.ini-conf zu überprüfen und Ihre Zeitzone einzustellen.
—
Sie erhalten dies, weil Sie den Thread verfasst haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm.

* * * * * * * * * * * Malayala Manorama * * * * * * * * * **
Der Inhalt dieser E-Mail (einschließlich des Inhalts der Beilage(n) oder Anhänge, falls vorhanden) sind privilegiertes und vertrauliches Material von Malayala Manorama (MM) und dürfen in keiner Weise weitergegeben, verwendet oder kopiert werden durch eine andere Person als den/die beabsichtigten Adressaten. Falls Sie nicht der gewünschte Adressat sind, sollten Sie diese Nachricht löschen und/oder an den Absender weiterleiten. Die in dieser E-Mail-Nachricht geäußerten Ansichten (einschließlich der Anlage(n) oder Anhänge, falls vorhanden) sind die des einzelnen Absenders, es sei denn, der Absender gibt ausdrücklich und mit Vollmacht an, dass es sich um die Ansichten von Malayala Manorama . handelt .
Diese E-Mail-Nachricht einschließlich Anhang(en) wird, falls vorhanden, als virenfrei angesehen. Es liegt jedoch in der Verantwortung des Empfängers sicherzustellen, dass es virenfrei ist und MM haftet nicht für Verluste oder Schäden, die in irgendeiner Weise aus seiner Verwendung entstehen.

Wenn die Zeit falsch ist, wie Sie sagen, wie sollte die Zeit sein? Um wie viel ist es weg?

Scheint, dass die Zeit der Zeitzone IST angezeigt wird (Interpretiert als
Asia/Jerusalem) nicht von Asia/Kolkata Ich brauche die Zeit von Asia/Kolkata für
Die Tickets.

Danke & Grüße
Lijo Joseph George
Technisches Team|| ManoramaOnline
Handy: +91 9895336448 | Büro : +91 0481 2563646 | Ext :670
Besuchen Sie uns: www.manoramaonline.com | LinkedIn | Facebook | Twitter

Von: Fabian Dellwing [email protected]
An: osTicket/osTicket [email protected]
Cc: lijo joseph george [email protected] , Autor
[email protected]
Datum: 02.06.2017 14:41
Betreff: Re: [osTicket/osTicket] Ticketzeit wird falsch angezeigt
(#3654)

Wenn die Zeit falsch ist, wie Sie sagen, wie sollte die Zeit sein? Um wie viel ist
es aus?
—
Sie erhalten dies, weil Sie den Thread verfasst haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm.

* * * * * * * * * * * Malayala Manorama * * * * * * * * * **
Der Inhalt dieser E-Mail (einschließlich des Inhalts der Beilage(n) oder Anhänge, falls vorhanden) sind privilegiertes und vertrauliches Material von Malayala Manorama (MM) und dürfen in keiner Weise weitergegeben, verwendet oder kopiert werden durch eine andere Person als den/die beabsichtigten Adressaten. Falls Sie nicht der gewünschte Adressat sind, sollten Sie diese Nachricht löschen und/oder an den Absender weiterleiten. Die in dieser E-Mail-Nachricht geäußerten Ansichten (einschließlich der Anlage(n) oder Anhänge, falls vorhanden) sind die des einzelnen Absenders, es sei denn, der Absender gibt ausdrücklich und mit Vollmacht an, dass es sich um die Ansichten von Malayala Manorama . handelt .
Diese E-Mail-Nachricht einschließlich Anhang(en) wird, falls vorhanden, als virenfrei angesehen. Es liegt jedoch in der Verantwortung des Empfängers sicherzustellen, dass es virenfrei ist und MM haftet nicht für Verluste oder Schäden, die in irgendeiner Weise aus seiner Verwendung entstehen.

Nun, das ist bereits bekannt: #3583

Habe hineingeschaut und bin total verwirrt...

In der ost_config ist also 'Asia/Kolkata' (+5:30) richtig, in class.format.php function datetime $cfg->getTimezone() ist 'Asia/Kolkata' (+5:30) aber 2 Sekunden später, nachdem wir es an IntlDateFormatter haben, sind wir in 'Asia/Jerusalem' (+4:30). Wie??

Edit: Habe es gefunden. Es ist ein Fehler in IntlDateFormatter .

<?php
$formatter = new IntlDateFormatter('de',3,3,'Asia/Kolkata',IntlDateFormatter::GREGORIAN,null);
    echo $formatter->format(time());
?>

Dies sollte 'jetzt + 5:30' sein, ist aber 'jetzt + 4:30'!

@fdellwing Wir sind bei mehreren Gelegenheiten auf dieses Problem

Noch nicht, Sie müssen sich IntlDateFormatter genauer ansehen, wenn es Workarounds gibt.

Ab #3583

dbinoj commented on Dec 31, 2016
The timezone returned by timezone_name_from_abbr can not be trusted as it just selects the first result sorting the tz name alphabetically. This messes up times displayed in the site even though timezone in OSTicket System Settings, OSTicket User Prefs, php.ini, MySQL, Server OS are all set to the same value.

Eg. IST refers to Israel/Indian/Irish Standard Times (Ref: List_of_time_zone_abbreviations)
One may intend to use Indian/Irish timezone but "Asia/Jerusalem" comes first alphabetically.
Few other TZs which I found to have duplicates are ACT, AMT, BST, etc.,

Either function get_from_database in class.timezone.php:165 should be modified to translate ambiguous timezones with some other reference value or a better method must be implemented.

Related StackOverflow answer: http://stackoverflow.com/a/30958892

Es scheint, als ob sich die Interpretation aus seltsamen Gründen ändern kann. CST db_timezone wurde in einer Testinstallation als UTC interpretiert... Ich habe den Server zweimal neu gestartet und hatte das gleiche Problem. Um es zu debuggen, habe ich angefangen php-devel, php-xdebug zu installieren und den Webserver neu zu starten... aber dann verschwand das Problem und CST wurde korrekt nach America/Chicago gelöst. 0_0

CST wird von timezone_name_from_abbr niemals als UTC interpretiert. Sie müssen ein anderes Problem gehabt haben. Haben Sie Ihre Datenbank manuell nach @@system_time_zone abgefragt? Die alte Version (ohne meine PR) fragt dafür einfach die DB ab.

So entfernen Sie das Zeitzonenproblem mit der osticket DB-Zeitzone als: IST (Interpretiert als Asien/Jerusalem)
http://osticket.com/forum/discussion/89257/v1-10-timezone-misinterpreted
https://github.com/osTicket/osTicket/issues/3654
https://github.com/osTicket/osTicket/issues/3583

Wir haben eine Schnellkorrektur in include/class.config.php durchgeführt

Suche nach Zeile mit
function getDbTimezone()

in dieser Funktion würden Sie die letzte Zeile als
return $this->get('db_timezone');
Kommentieren Sie diese Zeile und fügen Sie unter zwei Zeilen hinzu
$dvd_db_timezone='Asia/Kolkata'; return $dvd_db_timezone;

Die Funktion möchte unten.
function getDbTimezone() { if (!$this->exists('db_timezone')) { require_once INCLUDE_DIR . 'class.timezone.php'; $this->persist('db_timezone', DbTimezone::determine()); } $dvd_db_timezone='Asia/Kolkata'; return $dvd_db_timezone; // return $this->get('db_timezone'); }

Dies wird sehr hilfreich sein, bis die richtige Codekorrektur vorhanden ist.

Danke an alle,
Es wurde behoben

@deependhulla Ich hoffe, Sie möchten das nicht als gültige Lösung bewerben. Wenn Sie eine passende Lösung suchen, schauen Sie sich meine PR #3663 an

@fdellwing Mein Vorschlag ist für eine schnelle Lösung, damit die Arbeit besonders beginnen kann, wenn Sie sich auf die Implementierung von osticket freuen und alle korrekten Funktionen haben, aber die grundlegende Zeitzonenfunktion verursacht Probleme beim Start. Dies würde ihnen helfen, die Funktionen und die Leistung von octicket zu nutzen und zu erkunden.

Eigentlich würde es vorziehen, dieses Zeitzonenproblem so schnell wie möglich mit dem ursprünglichen Kern-Osticket zu beheben.
und/oder geben Sie die Option an, auch die Zeitzone für die Datenbank auszuwählen.

Insgesamt liebe ich Osticket.
Danke auch an das octicket-Team für dieses wundervolle Produkt.

Für Google-Mitarbeiter, wenn Ihre Datenbankzeit auf GMT eingestellt ist, liest OSTicket dies als "Europa/London" anstelle von UTC. Ihre Zeiten werden dann während der Sommerzeit um 1 Stunde unterbrochen. Um dies zu beheben, ändern Sie includes/class.config.php . Ändern Sie die Methode OsticketConfig::getDbTimezone wie folgt:

function getDbTimezone() {
        if (!$this->exists('db_timezone')) {
            require_once INCLUDE_DIR . 'class.timezone.php';
            $this->persist('db_timezone', DbTimezone::determine());
        }
        $db = $this->get('db_timezone');
        if ( $db === 'Europe/London') {
            $db = 'UTC';
        }
        return $db;
    }

@deependhulla ...Vielen Dank .... Sie haben eine richtige Lösung gegeben ... !!!

Trage dich

Ja, dieser Patch ist gut, aber das ist eine hartcodierte Funktion. Ich benutze Asien / Jekaterinburg (GMT +5.00), aber in osticket sehe ich das Ticketdatum als GMT +4.00.
@deependhulla danke

So entfernen Sie das Zeitzonenproblem mit der osticket DB-Zeitzone als: IST (Interpretiert als Asien/Jerusalem)
http://osticket.com/forum/discussion/89257/v1-10-timezone-misinterpreted

3654

3583

Wir haben eine Schnellkorrektur in include/class.config.php durchgeführt

Suche nach Zeile mit
function getDbTimezone()

in dieser Funktion würden Sie die letzte Zeile als
return $this->get('db_timezone');
Kommentieren Sie diese Zeile und fügen Sie unter zwei Zeilen hinzu
$dvd_db_timezone='Asia/Kolkata'; return $dvd_db_timezone;

Die Funktion möchte unten.
function getDbTimezone() { if (!$this->exists('db_timezone')) { require_once INCLUDE_DIR . 'class.timezone.php'; $this->persist('db_timezone', DbTimezone::determine()); } $dvd_db_timezone='Asia/Kolkata'; return $dvd_db_timezone; // return $this->get('db_timezone'); }

Dies wird sehr hilfreich sein, bis die richtige Codekorrektur vorhanden ist.

Hallo
Wir standen vor dem gleichen Problem und hatten den obigen Patch in 1.10.5 angewendet. Das hat gut funktioniert.

Wir haben jedoch kürzlich ein Upgrade auf 1.12.2 durchgeführt und alle unsere Ticketzeiten waren wieder seltsam, dieses Mal ging es um 2 Stunden 30 Minuten vor (als ob die Zeitzone +8 statt +5,30 wäre). Wir haben gerade den gleichen Patch angewendet und es scheint gut zu funktionieren.

Wird der Fehler noch vom 1.10. auf 1.12?

So entfernen Sie das Zeitzonenproblem mit der osticket DB-Zeitzone als: IST (Interpretiert als Asien/Jerusalem)
http://osticket.com/forum/discussion/89257/v1-10-timezone-misinterpreted

3654

3583

Wir haben eine Schnellkorrektur in include/class.config.php durchgeführt
Suche nach Zeile mit
function getDbTimezone()
in dieser Funktion würden Sie die letzte Zeile als
return $this->get('db_timezone');
Kommentieren Sie diese Zeile und fügen Sie unter zwei Zeilen hinzu
$dvd_db_timezone='Asia/Kolkata'; return $dvd_db_timezone;
Die Funktion möchte unten.
function getDbTimezone() { if (!$this->exists('db_timezone')) { require_once INCLUDE_DIR . 'class.timezone.php'; $this->persist('db_timezone', DbTimezone::determine()); } $dvd_db_timezone='Asia/Kolkata'; return $dvd_db_timezone; // return $this->get('db_timezone'); }
Dies wird sehr hilfreich sein, bis die richtige Codekorrektur vorhanden ist.

Hallo
Wir standen vor dem gleichen Problem und hatten den obigen Patch in 1.10.5 angewendet. Das hat gut funktioniert.

Wir haben jedoch kürzlich ein Upgrade auf 1.12.2 durchgeführt und alle unsere Ticketzeiten waren wieder seltsam, dieses Mal ging es um 2 Stunden 30 Minuten vor (als ob die Zeitzone +8 statt +5,30 wäre). Wir haben gerade den gleichen Patch angewendet und es scheint gut zu funktionieren.

Wird der Fehler noch vom 1.10. auf 1.12?

1.12 nicht bekannt .. aber dieser Fix funktionierte bei uns auf osTicket (v1.14.2) wieder.

Ich habe beide Lösungen ausprobiert und könnte mich irren, aber ich denke, keine hat für mich funktioniert. Ich habe auch gerade auf 1.14.2 aktualisiert, aber ich glaube nicht, dass es in dieser Version eine Lösung dafür gab.

Vor diesem Fix habe ich MST (Interpreted as America/Denver) mit einer Stunde weniger als meiner Zeit gesehen.

Nachdem ich die oben vorgeschlagene Lösung von Benutzer

Selbst wenn ich andere Zeitzonen versuche, die zeitlich fortgeschrittener sind, zum Beispiel "America/New_York", die 2 Stunden voraus ist und meine 2 Stunden kompensieren könnte, endet es 4 Stunden vorher nicht mehr.

Auch ich habe meine Serverzeit überprüft und sie ist in MST mit der richtigen Zeit. Ich habe dies überprüft, indem ich den Befehl "date" auf dem Terminal ausgeführt habe.

Hat noch jemand dieses Problem? Ich verstehe, dass das Problem geschlossen ist, aber ich kann es nicht beheben.

@perezalvarezhi

Wie ist Ihre Systemzeitzone eingestellt ( Admin Panel > Einstellungen > System > Datums- und Zeitoptionen > Standardzeitzone )? Ist es America / Mexico_City ?

Wie ist Ihre Profilzeitzone eingestellt ( Profil > Einstellungen > Lokalisierung > Zeitzone )?

Beifall.

@perezalvarezhi

Wie ist Ihre Systemzeitzone eingestellt ( Admin Panel > Einstellungen > System > Datums- und Zeitoptionen > Standardzeitzone )? Ist es America / Mexico_City ?

Wie ist Ihre Profilzeitzone eingestellt ( Profil > Einstellungen > Lokalisierung > Zeitzone )?

Beifall.

Hey @JediKev Ich denke, während du deine Fragen gelesen hast, hast du mir geholfen, es herauszufinden.
Ich musste die Standardzeitzone wie die meines Servers in Pacific eingeben (bevor ich angegeben habe, dass er auf MST ist, aber nicht auf Pacific) und dann mein Agentenprofil in der Zeitzone, in der es sich befindet.

Ich habe im Admin-Panel > Einstellungen > System > Datums- und Zeitoptionen > Standardzeitzone "America/Los_Angeles" ausgewählt und dann in meinen Profilen America/Mexico_City.

Auf diese Weise hat es gut funktioniert.

Vielen Dank!

@perezalvarezhi

Großartig! Ich freue mich, dass du das gelöst hast!

Beifall.

Hallo zusammen !
Ich weiß, dass wir 2020 haben, aber dieses Problem besteht immer noch ... Musste die Datei class.config.php bearbeiten und meine Zeitzone zurückgeben, damit dies funktioniert ... Danke
EDIT: Sorry, die neuesten Threads sind schon 2020. Ich verwende die neueste Version 1.14.3

@JediKev noch einer mit diesem Fehler

@antiuser

Cool.. Sie haben nie auf meine Nachricht in Ihrem Problemthread geantwortet. #5522

Beifall.

@JediKev Dieser Fehler wurde in der Version