nicht angemeldet
Probleme mit Zeitzonen
Hallo!
Ich habe ein kleines Problem, in meinem Diskussionsforum die richtige Zeitzone hinzukriegen. Das ganze läuft auf einem amerikanischen Server und natürlich ist die Zeit immer um 6 Stunden früher als hier. Ich habe auch schon im Archiv gesucht und etwas gefunden, aber das hat nicht funktioniert. Gibt es eine Einstellung, die man vornehmen kann (ist nicht mein Server, kann also die Config nicht ändern) oder muß man das ausprogrammieren?
Letzteres ist ziemlich unangenehm, weil die Amis ja keine Sommerzeit haben, soweit ich weiß. Und die Zeitumstellung ist auch nicht auf ein genaues Datum festgesetzt sondern immer am (wasweißichwievielten) Sonntag im Mai oder sowas. Wie programmiert man das bitte? :-)
Also vielleicht hat schon jemand Erfahrung mit diesem Problem (und vielleicht sogar eine Lösung). Würde mich freuen!
danke im Voraus
Thomas.
Ps: Wer Lust hat, kann auch gerne mal mein Forum testen und mir sagen was er davon hält (Adresse, siehe oben!). Bitte nicht von dem Blödsinn stören lassen, der schon drinnensteht :-)
-
Moin,
Ich habe ein kleines Problem, in meinem Diskussionsforum die richtige Zeitzone hinzukriegen. Das ganze läuft auf einem amerikanischen Server und natürlich ist die Zeit immer um 6 Stunden früher als hier. Ich habe auch schon im Archiv gesucht und etwas gefunden, aber das hat nicht funktioniert. Gibt es eine Einstellung, die man vornehmen kann (ist nicht mein Server, kann also die Config nicht ändern) oder muß man das ausprogrammieren?
ich stand vor kurzem (ich programmiere auch an einem Forum - in Perl allerdings ;-) vor dem gleichen Problem. Die Recherche hat mich (danke an alle Beteiligten) hierhin gefuehrt: http://www.ptb.de/deutsch/org/4/43/432/somn.htm
Daraus entstanden ist folgendes Perlmodul http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/selfforum/selfforum-cgi/shared/Time/German.pm?only_with_tag=HEAD, welches die eingebaute localtime-Funktion ueberschreibt und neudefiniert. Vielleicht hilft dir das ein bisschen weiter (ich kann naemlich kein/kaum PHP).
[...] weil die Amis ja keine Sommerzeit haben, soweit ich weiß.
doch, die meisten haben sie, allerdings ein bisschen verschoben;) das wurde alles in der Diskussion hier dazu erwaehnt (demnaecsht ist der Archivviewer fertig, dann kann man die Diskussion dort auch nachlesen)
HTH &
Viele Gruesse,
n.d.p.
-
Moin n.d.!
Daraus entstanden ist folgendes Perlmodul http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/selfforum/selfforum-cgi/shared/Time/German.pm?only_with_tag=HEAD, welches die eingebaute localtime-Funktion ueberschreibt und neudefiniert.
Mmh... bad style, wie man so schoen sagt. Sollte nicht der Benutzer des Moduls entscheiden koennen, ob er die Core-Funktion ueberschrieben haben will? Ich z.B. erlaube Modulen grundsaetzlich nicht, Funktionsnamen automatisch in meinen Namespace zu verteilen, sondern waehle lieber selber aus, was ich haben will. Das geht mit Deinem Modul aber wieder nicht, weil Du dort @EXPORT_OK nicht belegst. Solange es nur diese eine Funktion da gibt, waere das vielleicht nicht mal problematisch, aber was, wenn Du in Zukunft weitere Moeglichkeiten dazufuegst und dann ploetzlich eine Funktion des Hauptprogramms ueberschrieben wird, weil der Benutzer gezwungenermassen den Inhalt von @EXPORT zulassen musste? Daher denke ich, ist es besser, immer @EXPORT_OK zu verwenden, und @EXPORT nur dann, wenn sich der Sinn wirklich aufdraengelt (was mir aber noch nicht untergekommen ist).
So long
-
Moin Calo,
Mmh... bad style, wie man so schoen sagt. Sollte nicht der Benutzer des Moduls entscheiden koennen, ob er die Core-Funktion ueberschrieben haben will?
oehm...
use Time::German ();der Benutzer kann ja auch die (bald erscheinende ;) Anleitung lesen *g* (genau wie er die von World::Redefine lesen sollte...)
ich habs gern kurz und buendig. Wenn ich dem Programm sage, ich moechte die deutsche Zeit benutzen, moechte ich einfach sagen:use Time::German; # und fertig.
[...] weitere Moeglichkeiten dazufuegst und dann ploetzlich eine Funktion des Hauptprogramms ueberschrieben wird, weil der Benutzer gezwungenermassen den Inhalt von @EXPORT zulassen musste?
muessen muss er gar nix (s.o.). Fuer sowas (also Viel-Funktions-Export) biete ich dann meistens gruppierende EXPORT_TAGS an, bzw. beschraenke mich dann auch auf eine EXPORT_OK-Liste.
(Beispiel: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/selfforum/selfforum-cgi/shared/Posting/_lib.pm?only_with_tag=HEAD oder die alte Version des Lockmoduls: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/selfforum/selfforum-cgi/shared/Lock.pm?rev=1.10&content-type=text%2Fvnd.viewcvs-markupViele Gruesse,
n.d.p.
-
Hi again!
der Benutzer kann ja auch die (bald erscheinende ;) Anleitung lesen *g*
Muesste es nicht "Anleitung[tm]" heissen? ;-)
(genau wie er die von World::Redefine lesen sollte...)
ich habs gern kurz und buendig. Wenn ich dem Programm sage, ich moechte die deutsche Zeit benutzen, moechte ich einfach sagen:»»
use Time::German; # und fertig.
Kann ich ja verstehen, aber s.u. *g*
[...] weitere Moeglichkeiten dazufuegst und dann ploetzlich eine Funktion des Hauptprogramms ueberschrieben wird, weil der Benutzer gezwungenermassen den Inhalt von @EXPORT zulassen musste?
»»
muessen muss er gar nix (s.o.). Fuer sowas (also Viel-Funktions-Export) biete ich dann meistens gruppierende EXPORT_TAGS an, bzw. beschraenke mich dann auch auf eine EXPORT_OK-Liste.
Was ich meinte war, wenn das Mosul so wie jetzt verwendet wird, dann muss man eben doch die Default-Imports zulassen, weil Du ja @EXPORT_OK nicht belegt hast. Es sei dann natuerlich, man schreibt immer Time::German::localtime, aber wollen wir ja auch nicht. Wenn Du nun in beliebig naher oder ferner Zukunft nun vielleicht auch eine Funktion timelocal hinzufuegst, die man ja auch aus dem Standardmodul Time::Local beziehen kann, dann wird die dann ploetzlich auch mit importiert, wenn man auf die neue Modulversion updatet. Und dann gibt's echten Matsch. (Zugegeben, es waere wohl kaum sinnvoll, localtime von Deinem Modul zusammen mit dem timelocal von Time::Local zu verwenden, aber das ist ja nur ein Beispiel.)
So long
-
Moin,
Muesste es nicht "Anleitung[tm]" heissen? ;-)
hehe ;)
Was ich meinte war, wenn das Mosul so wie jetzt verwendet wird, dann muss man eben doch die Default-Imports zulassen, weil Du ja @EXPORT_OK nicht belegt hast. Es sei dann natuerlich, man schreibt immer Time::German::localtime, aber wollen wir ja auch nicht. Wenn Du nun in beliebig naher oder ferner Zukunft nun vielleicht auch eine Funktion timelocal hinzufuegst, die man ja auch aus dem Standardmodul Time::Local beziehen kann, dann wird die dann ploetzlich auch mit importiert, wenn man auf die neue Modulversion updatet. Und dann gibt's echten Matsch. (Zugegeben, es waere wohl kaum sinnvoll, localtime von Deinem Modul zusammen mit dem timelocal von Time::Local zu verwenden, aber das ist ja nur ein Beispiel.)
das ueberzeugt - zumindest bei internen Funktionen:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/selfforum/selfforum-cgi/shared/Time/German.pm?only_with_tag=HEADuse Time::German ':overwrite_internal_localtime'; # ;-))))
Viele Gruesse,
n.d.p.
-
-
-
-
-
Hallo!
Das ganze läuft auf einem amerikanischen Server und natürlich ist die Zeit immer um 6 Stunden früher als hier.
Letzteres ist ziemlich unangenehm, weil die Amis ja keine Sommerzeit haben, soweit ich weiß. Und die Zeitumstellung ist auch nicht auf ein genaues Datum festgesetzt sondern immer am (wasweißichwievielten) Sonntag im Mai oder sowas. Wie programmiert man das bitte? :-)
Also vielleicht hat schon jemand Erfahrung mit diesem Problem (und vielleicht sogar eine Lösung). Würde mich freuen!
Mhhh, weist Du warum es den Spruch "Zeit ist Geld" gibt? Weil man mit den ganzen Zeitberechnungen , also das schreiben der Scripte und austesten, ein Haufen Zeit(Arbeitszeit) verliert! ;-) Über diese ganzen Zeitberechnungen kannst Du bekloppt werde. Ich hatte mal ein Projekt gehabt, da habe ich ab und zu mal eine Stunde verloren... :-(!
Also, wie würde ich es angehen!
- Zeitstempel von der Maschine holen! mktime();
- Zeitstempel + 6 Stunden
Und jetzt kommt Dein Part. Da ich keine Maschine bei den Amis habe, mußt Du mal testen. In gettimeofday() kannst Du irgendwie die Sommerzeit mit berücksichtigen lassen.
http://www.php.net/manual/de/function.setlocale.php
http://www.php.net/manual/de/function.gettimeofday.php
http://www.php.net/manual/de/function.getdate.phpIch würde bei diesem Ministerium anrufen, siehe Link von n.d.parker. Bei denen mal nachfragen, wann die nächste Sommer -und Winterzeit anfängt. Für die nächsten 5 Jahre sollte wohl ausreichen. Das dann einfach in ein paar if-Abfragen packen.
MfG, André Laugks
-
Hallo!
... und danke erstmal an alle, die sich die Zeit genommen haben, um mir zu antworten.
Kaum zu glauben, aber die Lösung ist sooo einfach:
putenv("TZ=MET");
strftime("dummy");Tja, also das putenv stellt die richtige Zeitzone ein und weil php4 wohl einen Bug hat, muß man vorher mal die Funktion strftime aufrufen, ohne das Ergebnis irgendwie zu verwerten und dann kann man mit date() ganz normal Datum und Uhrzeit auslesen.
Ich hoffe, daß dieser Beitrag auch allen anderen hilft, die Probleme mit Datum und Uhrzeit haben, weil sie einen amerikanischen Server benutzen und dieser ja in einer anderen Zeitzohne ist. (Das habe ich nur geschrieben, damit dieser Threat auch mit allen möglichen Kombinationen im Archiv gefunden wird *g*)
Grüße
Thomas.
-
Moin,
Kaum zu glauben, aber die Lösung ist sooo einfach:
putenv("TZ=MET");
hmm, und was machst du mit der Sommerzeit (MEST)?
Viele Gruesse,
n.d.p.
-