Ausgabe der verschiedenen Zeiten

[evaki]

Hallo
Benötige die Ausgabe (echo...) der verschiedenen Zeiten (Zeitzone, Datum, aktuelle Zeit) für

die Lokale Serverzeit (PHP- Zeitzone/Zeit)
die unter Optionen eingestellte Zeitzone/Zeit
die unter Einstellungen (eingeloggter User) eingestellte Zeitzone/Zeit

Es soll mit code2 genauso funktionieren wie im Template
Meine Versuche sind bisher leider gescheitert

MfG. Evaki

[badknight]

Hallo
Benötige die Ausgabe (echo...) der verschiedenen Zeiten (Zeitzone, Datum, aktuelle Zeit) für

die Lokale Serverzeit (PHP- Zeitzone/Zeit)
die unter Optionen eingestellte Zeitzone/Zeit
die unter Einstellungen (eingeloggter User) eingestellte Zeitzone/Zeit

Es soll mit code2 genauso funktionieren wie im Template
Meine Versuche sind bisher leider gescheitert

MfG. Evaki

Hallo Evaki!

Im Developer Guide (klick me)

Findest du einige hilfreiche sachen:

$_SESSION['TIMEZONE'] => für die Zeitzone des eingeloggten Users
DEFAULT_TIMEZONE => 3600
DEFAULT_DATE_FORMAT => M d Y
DEFAULT_TIME_FORMAT => H:i

mehr infos bekommst du mit diesen kleinen helfern:

Definierte Konstanten anzeigen:

Code:

print_r(get_defined_constants());

Definierte Variablen anzeigen:

Code:

print_r(get_defined_vars());

Definierte Funktionen anzeigen:

Code:

print_r(get_defined_functions());

Für die Server - Zeit, hilft dir die PHP - Manual Seite weiter:

date_default_timezo ne_get
Gets the default timezone used by all date/time functions in a script


hoffe ich konnte dir weiter helfen

[evaki]

Da ich kein Programmierer bin, kann ich daraus keinen Nutzen ziehen.
Mit der Liste der Konst., Variabl. etc. hatte ich meine Versuche ja begonnen, sprich soweit war ich schon.
Nur dann verließen sie ihn 
Leider macht unser Ex-Admin nichts mehr mit WebsiteBaker, sonst hätte ich den gefragt.
MfG. Evaki

[badknight]

sag dochmal was du vor hast?

Ohne Programmier kentnissen wird es schwierig alleine.

[evaki]

Anhand der ausgegebenen Zeit(en) sollen weitere Aktionen (if/elseif-Komstrukt, was ich noch hinbekomme   ) ausgelöst werden.
Beispiele:
"Sendezeiten" 23.00Uhr-6.00Uhr > unterschiedlichen Content laden bzw. Content freigeben
Im Prinzip tageszeitabhängige Ausgaben machen > einzelne Blocke/Sektionen/Header(Design)
MfG. Evaki

[evaki]

Der Standard für die Ausgabe der Serverzeit (PHP) funktioniert seit WB2.8.2 nicht mehr, da die Entwicker per date_default_timezo ne_set die Serverzeit mit UTC überschreiben. Innerhalb von WebsiteBaker gibt es also keine Möglichkeit mehr, die Serverzeit (PHP) zu holen. Ich habe diesen "schmutzigen Patch" schon früh als falsch erachtet. Anscheinend interessiert es niemanden.
Mir bekannte Möglichkeiten:
Den Patch rausnehmen und erforderliche Anpassungen an den Modulen, wo nötig, vornehmen.
Extra Script außerhalb WebsiteBakers starten um sich die Serverzeit zu holen.

Warum innerhalb der Version 2.8.x derartige Änderungen vorgenommen werden, kann ich nicht nachvollziehen.
MfG. Evaki

[evaki]

Interessant auch die Diskussion zu Timezone unter PHP 5.4
http://www.mail-archive.com/internals@lists.php.net/msg55005.html

MfG. Evaki

[evaki]

Es ist schon mehr als merkwürdig, wenn ich mit meiner Frage von einem Entwickler auf das Forum verwiesen werde, hier jedoch keine Antwort auf die gestellte Frage und auch keine auf den m.E. vorhandenen Bug erhalte. Es existiert außerdem keine Roadmap und kein Zugang zu SVN, woraus man die weitere Entwicklung ableiten könnte. Derartige Enthaltsamkeit legt den Schluß nahe, daß man es mit Burgmentalität zu tun hat. Offenheit sieht anders aus. Wir haben bisher nur eine Domain mit einem WebsiteBaker v2.8.2 Update versehen. Wobei es wahrscheinlich bleiben wird, denn der Aufwand um alle installierten Komponenten nach dem Wechsel weiterhin lauffähig zu halten war immens. Nun laufen wir mit einer simplen Anfrage in die nächste Falle.

Halten wir mal fest, daß (normalerweise) auf

Code:

if (date_default_timezone_get()) {
    echo 'date_default_timezone_set: ' . date_default_timezone_get() . '<br />';
}

if (ini_get('date.timezone')) {
    echo 'date.timezone: ' . ini_get('date.timezone');
}

die Ausgabe folgt:
date_default_timezo ne_set: Australia/Melbourne
date.timezone: Australia/Melbourne


Mit dem seit v2.8.2 in der initialize.php gesetztem date_default_timezo ne_set('UTC');
sieht die Ausgabe so aus:
date_default_timezo ne_set: UTC
date.timezone: Australia/Melbourne

Da UTC statt für einzelne Anwendungen nun für das ganze CMS gilt, sind bestimmte vorgesehene Prozeduren nicht mehr möglich.
1.) Die lokale Serverzeit/Zeitzone kann nicht mehr eingeholt werden.
2.) Die automatische Umschaltung auf UTC, wenn keine -eben erst dann- TimeZone definiert ist, ist außer Kraft gesetzt

Statt nun CMS-weit UTC zu setzen, wäre es sinnvoll dies nur auf Scripte zu beschränken, die darauf "angewiesen" sind.

Jedenfalls wird hier schon wieder überlegt auf v2.8.1 zurück zu gehen.
Die Entscheidung, ob es bei der spärlichen und eingeschränkten Kommunikation überhaupt noch sinnvoll ist dieses CMS einzusetzen, steht noch aus.
Wir wollten ein durchgehend funktionstüchtiges CMS, was bis v2.8.1 anscheinend mit den üblichen kleinen zu nehmenden Hürden wunderbar funktionierte.

Den entstandenen Aufwand haben wir uns nur einmal geleistet. Ein zweites Mal werden wir das nicht mehr können.

MfG. Evaki

[jacobi22]

Jedenfalls wird hier schon wieder überlegt auf v2.8.1 zurück zu gehen. Die Entscheidung, ob es bei der spärlichen und eingeschränkten Kommunikation überhaupt noch sinnvoll ist dieses CMS einzusetzen, steht noch aus

Vielleicht solltet ihr mal die Reihenfolge der Entscheidungen prüfen  

[evaki]

Das zu beurteilen entzieht sich Deiner Kompetenz, ob nun die Dokumentation oder den Dialog mit Entwicklern betreffend.
Anscheinend reicht es aber auch nicht zu einer sachbezogenen Antwort. Es wurden -vielleicht ist das untergegangen- Fragen gestellt. Es wäre schön, wenn wir beim Topic bleiben könnten.
MfG. Evaki

[dbs]

Wenn es Probleme gibt ist es immer ärgerlich, da bin ich noch bei dir.
Aber worauf begründet sich dein gestellter Service-Anspruch?
Auf aktive Mitarbeit am Projekt, oder Spendenbeiträge oder Hilfe für andere User?

Man bedenke auch, dass Wochenende ist, dass Entwickler auch Zeit für andere nichtbezahlte Tätigkeiten brauchen.
Etwas Geduld könnte helfen.

[evaki]

Habe ab erstem Kontakt in dieser Sache gerechnet. Deshalb erscheint es gefühlt etwas länger.
Sicher, Geduld sollte man mitbringen; wir machen unsere Arbeit auch in unserer freien Zeit. Nur die Redakteure sind normale Angestellte, die im Rahmen ihrer Aufgaben auch mal schreiben.

Auf den gefühlten Bug wurde schon früh hingewiesen. Die Änderungen wurden von der Entwicklerseite aber gut begründet, wobei m.E. die jetzigen Probleme jedoch nicht berücksichtigt wurden. (...was normal wäre, denn jegliche Auswirkung zu kennen, geht sicher auch nicht) Daher auch mein Hinweis auf Änderungen an anderer Stelle statt zentral.

MfG. Evaki

[jacobi22]

Das zu beurteilen entzieht sich Deiner Kompetenz, ob nun die Dokumentation oder den Dialog mit Entwicklern betreffend.

das ist richtig und auch gut so

Anscheinend reicht es aber auch nicht zu einer sachbezogenen Antwort. Es wurden -vielleicht ist das untergegangen- Fragen gestellt.

Das zu beurteilen entzieht sich nun mal DEINER Kompetenz. Bei mir persönlich liegt es aber eher am Willen

Das Thema wurde ja nun schon öfter diskutiert. Im verlinktem Beitrag wurde auch mitgeteilt, was der Plan ist und warum welche Funktion nun wie geändert wurde bzw. wird. Wie ich sind wohl auch andere der Meinung, das es sich eben nicht um einen Bug handelt.

Für mich ist die dort geschilderte Zukunftsaussicht bezüglich der Zeitfunktionen die Richtung, die mir das Open Source CMS Websitebaker vorgibt. An dieser Variante haben Leute stunden- oder tagelang gearbeitet und es ist eine Variante, mit der die meisten Nutzer wohl gut leben können, auch, weil andere CMS genauso oder ähnlich arbeiten.
Und wenn nun ein einzelner kommt und solche (eigentlich für ein CMS grundlegenden) Zeitfunktionen in einer anderen Form benötigt oder erweitert haben möchte, dann steht es ihm frei, dies zu tun. Badknight hat alle notwendigen Infos dazu gegeben.

[evaki]

Rudimentäre Funktionen wie die angegebene werden in anderen bei uns laufenden CMS nicht außer Kraft gesetzt.
Ansonsten einfach mal die PHP-DOC und Kommentierungen lesen.
MfG. Evaki

[evaki]

Auf die Ausgangsfrage gibt es anscheinend eine Antwort:

Code:

if (date_default_timezone_get()) {
    echo 'date_default_timezone_set: ' . date_default_timezone_get() . '<br />';
}

if (ini_get('date.timezone')) {
    echo 'date.timezone: ' . ini_get('date.timezone');
}
//======================================
echo  "<br /><br />";
function f($tzIdentifier)
{
   echo $tzIdentifier, "\n",
       str_repeat('', strlen($tzIdentifier)), "\n";

    date_default_timezone_set($tzIdentifier);  

  echo(date('H:i:s'));    
    
    echo "\n <br />";
}


f('Australia/Melbourne');
f('Europe/Berlin');
f('UTC');

Output:

Code:

date_default_timezone_set: UTC
date.timezone: Australia/Melbourne

Australia/Melbourne 01:17:45
Europe/Berlin 15:17:45
UTC 14:17:45

Somit kann, wenn kein Denkfehler vorliegt, unabhängig von Voreinstellungen die gewünschte Ortszeit abgefragt werden.

Vielleicht kann das ja jemand überprüfen.

Falls es funktioniert, lassen sich tageszeitabhängige Ausgaben -per code2- leicht realisieren.

MfG. Evaki

[DarkViper]

Man merkt, es weihnachtet sehr.
'Alle Jahre wieder...'
 Vor ziemlich genau einem Jahr habe ich bereits auf die Problematik und die dafür geplante Lösung hingewiesen:
Ich wünsch dann auch mal Wild Rum

Einer meiner letzten Posts zu diesem Thema war: Falsche Uhrzeit WebsiteBaker 2.8.2  (30.09.2011)

Eigentlich dachte ich ja, dass dieses Thema allgemein und vor allem bei Modulentwicklern eine Menge Fragen aufwirft. Dementsprechend wunderte ich mich, dass anscheinend absolut alle die ganze Problematik auf Anhieb verstanden haben. Bis heute kamen keine Anfragen zum zukünftigen Handling der Zeitberechnung. Mal abgesehen von diversen Kommentaren, die jedoch keinerlei ernsthaft durchdachten, konstruktiven Hintergrund hatten.

Prinzipiell hat die lokale Zeit eines Servers niemals etwas in der Datenbank oder auch innerhalb eines Scriptes verloren. Das ist das irrelevanteste Datum das es überhaupt gibt.

Nemen wir an, ein Webspace ist auf einem Berliner Server gehostet. Viele Datensätze werden mit dem Timestamp des Servers gespeichert. Da der Server jedoch zu teuer ist, wird der Webspace auf einen Server in den USA verschoben und nachfolgende Datensätze werden wiederum mit dem Server-Timestamp gespeichert. Jetzt gibt es aber ein kleines Problem: Alle am alten Standort gespeicherten Datensätze haben jetzt um 6-9 Stunden verschobene Timestamps! Oder sind die neuen gegenüber den alten verschoben? Oder gar eine Stunde mehr oder weniger, je nach Sommer-/Winterzeit??  Irgendwie ist jetzt alles undefiniert und unklar. Viel Spass beim Umrechnen. Ups.... von wo nach wo eigentlich? Auf welcher Basis? Was war die alte Zeitzone.... eventuell noch einen Umzug früher?

Der einzig sinnvolle, absolut logische Weg, all diese Probleme in den Griff zu bekommen, ist der konsequente  Einsatz einer überall auf der Welt gültigen, einheitlichen, neutralen Zeitangabe. Und das ist nun mal die Coordinated Universal Time, kurz UTC genannt.

Wird also innerhalb des Systems nur noch mit UTC gearbeitet, so gibt es exakt nur noch 2 Stellen, an denen auf lokale Zeitangaben Rücksicht genommen werden muss.

• lokale Zeit-/Datumsangaben in Eingabeformularen müssen nach UTC umgerechnet werden
• Zur Anzeige auf Seiten muss die UTC im jeweiligen, lokalen Format ausgegeben werden.

Beides lässt sich mit 2 kleinen, recht simplen (noch zu erstellenden) Core-Funktionen, bzw. Methoden der zukünftigen, zentralen Date-/Time-Klasse einfach 'erschlagen'.

Eine Funktion, die die Anzeigeformatierung übernimmt, könnte etwa so aussehen:

Code:

<?php

// zentrale Formatierungsfunktion:
function utcTime($timestamp, $format, $timezone) {
$date = new DateTime('@'.(string)$timestamp, new DateTimeZone($timezone));
$retval = $date->format($format);
unset $date;
return $retval;
}

// Beispielaufruf::
echo utcTime($timestamp, 'd.m.Y H:i:s', 'Europe/Berlin');

?>

[evaki]

Danke für die (erneute) Aufklärung (Das ist jetzt archiviert   )
Unter "Falsche Uhrzeit WebsiteBaker 2.8.2  (30.09.2011)" hatte ich abschließend die Entwicklung begrüßt.
Doch stolperte ich aktuell über die lokale Serverzeit, die ich im Gegensatz zu Dir noch für wichtig halte, was den Anwendungen in anderen CMS geschuldet ist, wo mit der Abfrage autom. auch die Sommer-/Winterzeit auf einfachste Weise realisiert wird, weil hierfür die lokale Serverzeit genutzt wird. Auch unsere autom. Umschaltung in WebsiteBaker funktionierte so bis v2.8.1. Da unser Ex-Admin nichts mehr mit  WebsiteBaker macht, wissen wir nicht, ob das ganze noch aktiv ist. Deshalb gab's die Frage nach der Anzeige der oben genannten Zeiten, weil wir sehen wollten, ob es noch funktioniert. Vielleicht kriegen wir ihn ja noch einmal zu fassen.
MfG. Evaki

[Stefek]

Ach die liebe Zeit. Immer haben wir zu wenig davon und oft scheint sie einen durcheinander zu bringen.
Das Zeitproblem ist wohl nicht nur auf die EDV Ausgabe berschränkt. Der Zeitdruck lauert quasi an jeder Ecke.

Macht man ein einschlägiges Werk zum Thema PHP auf, wird man mit verschiedenen Zeit-Funktionen und -Klassen nur so überschüttet. Da stellt sich die Frage, ob die verschiedenen Herangehensweisen dazu gedacht sind, das Problem nun für alle Zeiten zu lösen, oder daraus hervorgehen, dass die vorige Funktion nicht verstanden wurde.
In der Praxis beobachte ich immer, je vielfältiger die Ansätze, um so weniger wurde das Problem wirklich angeschaut. Und das ist das Problem - Zeit ist schwer zu sehen. Man kann sie kaum bildlich darstellen. Anders also als bei, zum Beispiel, der Berechnung von Gruppenabhängigkeiten einzelner User im System, die ganz klar tabelarisch oder anhand eines simplen Organigramms dargestellt werden können, ist es bei dem Thema Zeit kaum möglich. Das Prinzip der Architektur ist: was sich bildlich schwer darstellen läßt, ist in der Praxis schwer umzusetzen. Kein Wunder, dass gekonnte Programmierer stets mit einem Bleistift und Papier zur Hand arbeiten.

Ich kann nur eine Empfehlung aussprechen: lasst euch nicht von der Zeit verrückt machen. Kommt Zeit, kommt Rat.


Gruß,
Stefek

[evaki]

Unser Ex-Admin hat mitgelesen.
Wir bekommen ein neues Script für v2.8.2, womit es wie bisher laufen soll (Autom. Sommerzeit).
MfG. Evaki

p.s. @DarkViper
Anhand des neuen Scripts ((Autom. Sommerzeit)) habe ich es jetzt nachvollziehen können. (Nicht falsch, aber viel zu kompliziert gedacht)

[evaki]

Trotz aller Argumente, die hier hin und hergeschoben wurden: Es reicht.
Nun haben wir zwei Domains testweise mit v.2.8.2 SP2 laufen.
Beim Gästebucheintrag sind unterschiedliche Zeitstempel zu sehen. Die eine Domain zeigt UTC, die andere die Ortszeit.
Bei diesen Ergebnissen ist es uns egal welch tollen Weg WebsiteBaker noch gehen soll.
Uns entnervt WebsiteBaker v2.8.2 nur noch.

MfG. Evaki

Korrektur:
Da lagen wohl die Nerven blank
Der Fehler war hausgemacht!
Peinlich, aber wenn was falsch ist.......

Die zusätzliche Angabe der Zeitzone (wie schon mal angesprochen) werden wir uns bei Bedarf dann dazubasteln.
 

[ruebenwurzel]

@evaki

Trotz aller Argumente, die hier hin und hergeschoben wurden: Es reicht.
Nun haben wir zwei Domains testweise mit v.2.8.2 SP2 laufen.
Beim Gästebucheintrag sind unterschiedliche Zeitstempel zu sehen. Die eine Domain zeigt UTC, die andere die Ortszeit.
Bei diesen Ergebnissen ist es uns egal welch tollen Weg WebsiteBaker noch gehen soll.
Uns entnervt WebsiteBaker v2.8.2 nur noch.

MfG. Evaki

Korrektur:
Da lagen wohl die Nerven blank
Der Fehler war hausgemacht!
Peinlich, aber wenn was falsch ist.......

Die zusätzliche Angabe der Zeitzone (wie schon mal angesprochen) werden wir uns bei Bedarf dann dazubasteln.
 

- offtopic -
Ich frag mich nur, ist das jetzt größer oder kleiner NULL         
- offtopic ende -

Schöne Feiertage wünscht
Matthias

[badknight]

@evaki

Trotz aller Argumente, die hier hin und hergeschoben wurden: Es reicht.
Nun haben wir zwei Domains testweise mit v.2.8.2 SP2 laufen.
Beim Gästebucheintrag sind unterschiedliche Zeitstempel zu sehen. Die eine Domain zeigt UTC, die andere die Ortszeit.
Bei diesen Ergebnissen ist es uns egal welch tollen Weg WebsiteBaker noch gehen soll.
Uns entnervt WebsiteBaker v2.8.2 nur noch.

MfG. Evaki

Korrektur:
Da lagen wohl die Nerven blank
Der Fehler war hausgemacht!
Peinlich, aber wenn was falsch ist.......

Die zusätzliche Angabe der Zeitzone (wie schon mal angesprochen) werden wir uns bei Bedarf dann dazubasteln.
 

- offtopic -
Ich frag mich nur, ist das jetzt größer oder kleiner NULL         
- offtopic ende -

Schöne Feiertage wünscht
Matthias

eine berechtigte Frage!

Trotz aller Argumente, die hier hin und hergeschoben wurden: Es reicht.
Nun haben wir zwei Domains testweise mit v.2.8.2 SP2 laufen.
Beim Gästebucheintrag sind unterschiedliche Zeitstempel zu sehen. Die eine Domain zeigt UTC, die andere die Ortszeit.
Bei diesen Ergebnissen ist es uns egal welch tollen Weg WebsiteBaker noch gehen soll.
Uns entnervt WebsiteBaker v2.8.2 nur noch.

MfG. Evaki

Korrektur:
Da lagen wohl die Nerven blank
Der Fehler war hausgemacht!
Peinlich, aber wenn was falsch ist.......

Die zusätzliche Angabe der Zeitzone (wie schon mal angesprochen) werden wir uns bei Bedarf dann dazubasteln.
 

Freut uns wenn es nun klappt

[evaki]

ist das jetzt größer oder kleiner NULL

Wenn ich die Frage recht verstehe, kann man annehmen, daß es (Korrektur) größer als Null ist. da es das Eingeständnis  eines Fehlers ist, was in unserem Kulturkreis meist ein soziales Plus darstellt. Verstehe jetzt nur nicht, warum das thematisiert wird.
MfG. Evaki

[kweitzel]

@evaki: Du hast recht, das hat nichts mit der Sache zu tun. Daher bitte ich auch damit aufzuhören.

Danke und Gruß

Klaus