mysql Sommer-/Winterzeit
0 0 
Tobias Kloth
0 0 Tobias Kloth
0 0 Tobias Kloth
0
mysql Sommer-/Winterzeit
Hi,
ich möchte in einer MySQL - Tabelle so was wie einen Terminplaner speichern. Es ist bei der Anwendung ziemlich wichtig, dass die Zeiten exakt stimmen, desshalb wollte ich vorsichtshalber mal nachfragen (habe in der MySQL Doku auch nichts gefunden):
date("H", strtotime($Auftrag["Termin"]))
$Auftrag["Termin"] ist das Ergebnis vom Auslesen eines DATETIME Feldes
Da müsste doch ein während der Winterzeit eingegebener Termin, der während der Sommerzeit ist, korrekt behandelt werden, oder?
Danke für eure Bemühungen,
Tobias
-
Hi Tobias,
Ich denke das kommt auf deinen Rechner an auf dem die Datenbank läuft.
Denn die Uhrzeit des Rechners ist ausschlaggebend für die richtige Uhrzeit.Insofern sollte er meiner Meinung nach alles richtig machen, da ja dein Rechner auch immer Winter und Sommerzeit automatisch ändert.
mfG - Alex
-
Hi Alex,
danke für deine Antwort.
Insofern sollte er meiner Meinung nach alles richtig machen, da ja dein Rechner auch immer Winter und Sommerzeit automatisch ändert.
Naja, aber jenachdem, wie das in der Datenbank gespeichert wird muss es ja nicht unbedingt klappen. Wenn es z.B. einfach ein Unix Timestamp wäre, bei dem zum aktuellen Timestamp die nötigen Sekunden einfach dazugerechnet würden, könnte es ja auch passieren, dass diese Zeitumstellung nicht mit einberechnet würde!
Tobias
-
Nein, weil gerade ein Timestamp fest definiert ist.
Dieser Timestamp gibt immer die genaue uhrzeit aus, sonst würden sich in ALLEN scripten auch immer die Postdaten ändern.Alle würden je nach sommer oder winterzeit eine stunde vor oder zurück gesetzt werden.
Wenn du dir dennoch unsicher bist, dann lade einen termin hoch und ändere die Zeit am server (falls dir das möglich ist) und probiere aus, ob der Termin richtig angezeigt und ausgeführt wird.
mfG - Alex
-
Hi Alex,
stimmt auch wieder.
Danke!Tobias
-
-
echo $begrüßung;
Wenn es z.B. einfach ein Unix Timestamp wäre, [...] könnte es ja auch passieren, dass diese Zeitumstellung nicht mit einberechnet würde!
Der Unix-Timestamp ist weltweit eindeutig definiert. Er gibt immer die Anzahl der Sekunden seit 1.1.1970 0:00 Uhr UTC an. Eine lokaler Gesetzgebung beeinflusst den Unix-Timstamp nicht, muss aber bei Umrechnung in die lokale Zeit berücksichtigt werden. Dies sollten aber die Systemroutinen von allein hinbekommen, wenn das System richtig konfiguriert ist.
echo "$verabschiedung $name";
-
Hi,
ich glaube, ich habe den immer "misbraucht", indem ich immer so getan habe, als ob er in MEZ laufen würde. Naja - bei den bisherigen Anwendungen war es auch egal!Tobias
-
-
-
Moin!
Ich denke das kommt auf deinen Rechner an auf dem die Datenbank läuft.
Denn die Uhrzeit des Rechners ist ausschlaggebend für die richtige Uhrzeit.Das würde ich nicht sagen. Rechneruhren können auch ganz schön falsch gehen. Und die Definition der "richtigen Uhrzeit" wäre auch mal interessant. :)
Insofern sollte er meiner Meinung nach alles richtig machen, da ja dein Rechner auch immer Winter und Sommerzeit automatisch ändert.
Aber wenn jemand in der Sommerzeit lebt und einen Termin in der Winterzeit eingibt, oder daran erinnert werden will, dann gibt es Überschneidungsprobleme.
Auf der Erde definiert sich ein Zeitpunkt nicht nur durch die Angabe von Datum und Uhrzeit, wie im DATETIME-Feld von MySQL möglich, sondern immer auch durch die Angabe einer Zeitzone, in der diese Zeitpunktangabe gelten soll. Der 1.1.2006 0:00 Uhr findet bekanntlich auf der Welt reihum zu jeder Stunde statt. Wer sich also um 0:00 Uhr verabredet zum Anstoßen mit Sekt, der sollte unbedingt die Zeitzone mitteilen.
In manchen Kontexten ist die Zeitzone implizit definiert, weil sämtliche Daten sich nur auf eine einzige Zeitzone beziehen. Aber bereits mit der Problematik "Sommerzeit" wird's interessant, denn alle Länder stellen eigentlich nicht an der Uhrzeit, sondern wechseln die Zeitzone von MEZ (UTC+01:00) auf MESZ (UTC+02:00) und zurück. Und mal ganz abgesehen davon gibt's außerdem ja das Problem, dass Bewohner einer Zeitzone im Urlaub diese auch gerne mal verlassen - dank Internet aber auch unterwegs ihren Erinnerungskalender dabeihaben können.
Eine Internetanwendung kann sich also nicht darauf verlassen, dass der Benutzer sich schon irgendwie selbst seine Uhrzeit zurechtschnitzt, weil der Server sonst ständig die eigene Uhr umstellen müßte - was für einen oder mehrere Benutzer in der gleichen Zeitzone noch funktionieren würde, für mehrere Benutzer in unterschiedlichen Zeitzonen aber nicht mehr geht.
Deshalb: Die Zeitpunkte immer in UTC (auch bekannt als "Greenwich-Zeit") abspeichern, und dabei berücksichtigen, in welcher Zeitzone dieser Zeitpunkt gelten soll. 12:00 Mittags im sommerlichen Deutschland ist eben nur 10:00 UTC, im Winter ist es 11:00 UTC. Wenn die Serveruhr ebenfalls auf UTC läuft (und zur Zeitanzeige die lokale Zeitzone des Admins draufrechnet), wird der Server pünktlich um 10:00 UTC "klingeln" können, und die angegebene Uhrzeit auch wieder in "12:00 MESZ" umrechnen können.
Wenn der Benutzer den Kalender aus einer anderen Zeitzone (z.B. Moskau, UTC+04:00) abfragt, würde es bei ihm erst um 14:00 lokaler Zeit "klingeln".
Das ist andererseits natürlich etwas nervig. Wenn man zuhause plant, um Urlaub um 8:00 Uhr geweckt zu werden, man kennt aber die Zeitzone des Ortes nicht, wird man eben um 8:00 Uhr "Zuhause-Zeit" geweckt - das kann nachts um 2 Uhr sein, oder nachmittags um 15:00. Mindestens müßte das Programm erkennen, dass man auch zur Winterzeit die Uhrzeiten im Sommer tatsächlich als Sommerzeit meint - und entsprechend die Stunde Zeitverschiebung berücksichtigen.
- Sven Rautenberg
--
My sssignature, my preciousssss!-
Hi,
danke erst mal für diese ausfürliche Antwort.Das würde ich nicht sagen. Rechneruhren können auch ganz schön falsch gehen. Und die Definition der "richtigen Uhrzeit" wäre auch mal interessant. :)
Also die Uhr auf dem Server läuft ziemlich exakt und die Zeitzone ist unsere hier (mitteleuropäische Zeit).
Aber wenn jemand in der Sommerzeit lebt und einen Termin in der Winterzeit eingibt, oder daran erinnert werden will, dann gibt es Überschneidungsprobleme.
Also doch Probleme?
Auf der Erde definiert sich ein Zeitpunkt nicht nur durch die Angabe von Datum und Uhrzeit, wie im DATETIME-Feld von MySQL möglich, sondern immer auch durch die Angabe einer Zeitzone, in der diese Zeitpunktangabe gelten soll. Der 1.1.2006 0:00 Uhr findet bekanntlich auf der Welt reihum zu jeder Stunde statt. Wer sich also um 0:00 Uhr verabredet zum Anstoßen mit Sekt, der sollte unbedingt die Zeitzone mitteilen.
Das Programm wird nur innerhalb Deutschlands genutzt (eventuell später auch in Österreich, aber das sollte ja auch nichts ausmachen).
In manchen Kontexten ist die Zeitzone implizit definiert, weil sämtliche Daten sich nur auf eine einzige Zeitzone beziehen. Aber bereits mit der Problematik "Sommerzeit" wird's interessant, denn alle Länder stellen eigentlich nicht an der Uhrzeit, sondern wechseln die Zeitzone von MEZ (UTC+01:00) auf MESZ (UTC+02:00) und zurück. Und mal ganz abgesehen davon gibt's außerdem ja das Problem, dass Bewohner einer Zeitzone im Urlaub diese auch gerne mal verlassen - dank Internet aber auch unterwegs ihren Erinnerungskalender dabeihaben können.
Ja schon, aber das Programm verwaltet Lieferungsdaten einer Firma, die fest an einem Platz steht und nicht in Urlaub geht und so *g*.
In diesem Fall ist auch ziemlich sicher, dass das Programm nicht aus dem Ausland bedient wird.Eine Internetanwendung kann sich also nicht darauf verlassen, dass der Benutzer sich schon irgendwie selbst seine Uhrzeit zurechtschnitzt, weil der Server sonst ständig die eigene Uhr umstellen müßte - was für einen oder mehrere Benutzer in der gleichen Zeitzone noch funktionieren würde, für mehrere Benutzer in unterschiedlichen Zeitzonen aber nicht mehr geht.
Aber ich verlasse mich darauf, dass das Datum immer in MEZ (oder halt MESZ, wenns in dieser Zeit liegt) angegeben wird. Darauf wird auch hingewiesen.
Deshalb: Die Zeitpunkte immer in UTC (auch bekannt als "Greenwich-Zeit") abspeichern, und dabei berücksichtigen, in welcher Zeitzone dieser Zeitpunkt gelten soll. 12:00 Mittags im sommerlichen Deutschland ist eben nur 10:00 UTC, im Winter ist es 11:00 UTC. Wenn die Serveruhr ebenfalls auf UTC läuft (und zur Zeitanzeige die lokale Zeitzone des Admins draufrechnet), wird der Server pünktlich um 10:00 UTC "klingeln" können, und die angegebene Uhrzeit auch wieder in "12:00 MESZ" umrechnen können.
Muss ich das, wenn oben beschriebenes Zutrifft, wirklich machen?
Das ist andererseits natürlich etwas nervig. Wenn man zuhause plant, um Urlaub um 8:00 Uhr geweckt zu werden, man kennt aber die Zeitzone des Ortes nicht, wird man eben um 8:00 Uhr "Zuhause-Zeit" geweckt - das kann nachts um 2 Uhr sein, oder nachmittags um 15:00. Mindestens müßte das Programm erkennen, dass man auch zur Winterzeit die Uhrzeiten im Sommer tatsächlich als Sommerzeit meint - und entsprechend die Stunde Zeitverschiebung berücksichtigen.
Ist das wirklich nötig, wenn ich immer in der gleichen Zeitzone bin (die Firma wird immer nur in Deutschland oder Österreich arbeiten, die arbeiten nicht im Urlaub).
Danke nochmal,
Tobias -
Hallo Sven,
bei dem ganzen Gehabe um Sommer- und Winterzeit frage ich mich, ob es nicht viel sinnvoller wäre, die Zeit auf dem Normalwert zu belassen (also UTC-Zeit + 1 Stunde, bzw. bei anderen Zeitzonen entsprechend).
Wie man auf Wikipedia nachlesen kann, ist knapp die Hälfte der Bevölkerung gegen die Sommerzeit eingestellt.Auch meiner Meinung nach wäre es besser, eine konstante Zeit zu haben - die Umstellung von Sommer- auf Winterzeit und umgekehrt ist doch immer viel zu aufwendig. Vor allem für informatische Probleme.
Was meint ihr dazu?
Grüße
Marc Reichelt || http://www.marcreichelt.de/
--
Linux is like a wigwam - no windows, no gates and an Apache inside!
Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)
http://emmanuel.dammerer.at/selfcode.html-
Hi,
bei dem ganzen Gehabe um Sommer- und Winterzeit frage ich mich, ob es nicht viel sinnvoller wäre, die Zeit auf dem Normalwert zu belassen (also UTC-Zeit + 1 Stunde, bzw. bei anderen Zeitzonen entsprechend).
stimmt schon, da kommt man eh immer nur durcheinander (es fehlt gedanklich immer eine Stunde oder ist zu viel da). Und die ganzen alten Uhren muss man extra mit der Hand umstellen.
Und überhaupt: Dann ist es für ein paar Tage morgends hell aber wenn, dann müsste man ja eigentlich mehrmals die Zeit umstellen.Aber das hilft mir halt derzeit auch nicht weiter - ich habe das schneller ins Programm eingebunden, als mal eben ein paar Verfassungsklagen und Petitionen zu initiieren *g* !
Tobias
-
Hallo Tobias!
bei dem ganzen Gehabe um Sommer- und Winterzeit frage ich mich, ob
es nicht viel sinnvoller wäre, die Zeit auf dem Normalwert zu
belassen (also UTC-Zeit + 1 Stunde, bzw. bei anderen Zeitzonen
entsprechend).stimmt schon, da kommt man eh immer nur durcheinander (es fehlt
gedanklich immer eine Stunde oder ist zu viel da). Und die ganzen
alten Uhren muss man extra mit der Hand umstellen.
Und überhaupt: Dann ist es für ein paar Tage morgends hell aber
wenn, dann müsste man ja eigentlich mehrmals die Zeit umstellen.Zudem: Der eigentliche Argumentationspfeiler des Stromsparens ist
heute sowieso längst unbedeutend, da die Zeit, in der elektr. Licht
der Hauptverbraucher elektr. Energie war, wohl vorbei ist.℆, ℒacℎgas
--
Bei der intendierten Realisierung der linguistischen Simplifizierung
des regionalen Idioms resultiert die Evidenz der Opportunität extrem
apparent, den elaborierten und quantitativ opulenten Usus nicht assi-
milierter Xenologien konsequent zu eliminieren!-
Hi,
Zudem: Der eigentliche Argumentationspfeiler des Stromsparens ist
heute sowieso längst unbedeutend, da die Zeit, in der elektr. Licht
der Hauptverbraucher elektr. Energie war, wohl vorbei ist.hätte ich vor meinem Kommentar lesen sollen - habe es ja eh nur anders formuliert!
Tobias
-
-
-
Hallo Marc!
Wie man auf Wikipedia nachlesen kann, ist knapp die Hälfte der
Bevölkerung gegen die Sommerzeit eingestellt.Ich folgere: Dann müsste mehr als die Hälfte dafür sein (oder ein
paar Prozent "Weiß nicht")?„Traue keiner Statistik, die Du nicht selber gefälscht hast.“
℆, ℒacℎgas
--
Bei der intendierten Realisierung der linguistischen Simplifizierung
des regionalen Idioms resultiert die Evidenz der Opportunität extrem
apparent, den elaborierten und quantitativ opulenten Usus nicht assi-
milierter Xenologien konsequent zu eliminieren!-
Hi,
aber wer soll den für so einen Mist sein.
Ja, zum Stromsparen.
Klar - wer braucht schon mit Beleuchtung annähernd so viel wie mit PC, TV, ...
Also ich finde es einfach überflüssig!
Vermutlich 49 % dagegen, 50% weiß nicht, 1% dafür *g*!Tobias
-
-
-
-
-
Hallo Tobias,
date("H", strtotime($Auftrag["Termin"]))
Was hast du gegen ein "
DATE_FORMAT(Termin,'%H') as Termin" beim Abfragen des Termins aus der Datenbank?Grüße aus Nürnberg
Tobias-
Hi Tobias,
date("H", strtotime($Auftrag["Termin"]))
Was hast du gegen ein "DATE_FORMAT(Termin,'%H') as Termin" beim Abfragen des Termins aus der Datenbank?Ich frage eine ganze Zeile aus einer Tabelle auf einmal ab und schreibe die in einen Array (so, dass jedes Element des Arrys den Namen hat, den die entsprechende Zeile in der MySQL-Tabelle auch hat!
Dadurch wäre dies etwas umständlicher - hat es denn erhebliche Vorteile?Grüße aus Nürnberg
TobiasGrüße aus Nürnberg
Tobias-
Hallo Tobias,
Ich frage eine ganze Zeile aus einer Tabelle auf einmal ab und schreibe die in einen Array (so, dass jedes Element des Arrys den Namen hat, den die entsprechende Zeile in der MySQL-Tabelle auch hat!
Das ist mir schon klar - nur wenn du DATE_FORMAT() verwendest, musst du auf die ausgelesenen Daten nicht nochmal date() anwenden, da das DATE_FORMAT() dann schon gemacht hat.
Grüße aus Nürnberg
Tobias-
Hallo Tobias,
Ich frage eine ganze Zeile aus einer Tabelle auf einmal ab und schreibe die in einen Array (so, dass jedes Element des Arrys den Namen hat, den die entsprechende Zeile in der MySQL-Tabelle auch hat!
Das ist mir schon klar - nur wenn du DATE_FORMAT() verwendest, musst du auf die ausgelesenen Daten nicht nochmal date() anwenden, da das DATE_FORMAT() dann schon gemacht hat.Ja, aber ob ich das Datum jetzt von MySQL oder PHP in Tag, Monat, Jahr, Stunde, Minute zerlegen lass ist doch eigentlich egal, oder habe ich da was übersehen?
Tobias
-
Hallo Tobias,
Ja, aber ob ich das Datum jetzt von MySQL oder PHP in Tag, Monat, Jahr, Stunde, Minute zerlegen lass ist doch eigentlich egal, oder habe ich da was übersehen?
Wenn du das über PHP machst, brauchst du zwei Funktionen, im Query dagegen nur eine - warum soll die Datenbank nicht ewas machen was sie (sehr) gut kann?
Grüße aus Nürnberg
Tobias--
TOP7: Hinweise, dass du langsam taub wirst
Selfcode: ie:% fl:( br:< va:) ls:[ fo:) rl:° n4:& ss:) de:] js:| ch:? sh:( mo:| zu:)-
Hi Tobias,
Wenn du das über PHP machst, brauchst du zwei Funktionen, im Query dagegen nur eine - warum soll die Datenbank nicht ewas machen was sie (sehr) gut kann?
Stimmt eigentlich.
Ich dacht nur, weil ich dann halt nicht einfach
$Auftrag = mysql_fetch_array(mysql_query("select * from auftraege where Auftragsnummer = \"".$_POST["Auftragsnummer"]."\""), MYSQL_ASSOC);
sagen kann!Tobias
-
Hallo Tobias,
Ich dacht nur, weil ich dann halt nicht einfach [...] sagen kann!
Dass soll man auch aus 4 Gründen nicht:
[code lang=mysql]
btw: lang=mysql gibt es nicht, hier wäre aber sowieso ein lang=php angebracht ggf. den Query nochmal in ein lang=sql schachteln.
$Auftrag = mysql_fetch_array(mysql_query(
sowas ist _ganz_ schlecht - das erschwert die Fehlersuche drastisch. Du solltest dir angewöhnen, ersten den Query einer Variable zuzuweisen, dann mysql_query() aufzurufen (mit Fehlerbehandlung) und erst dann mysql_fetch_array() aufzurufen (wieder Fehlerbehandlung einbauen).
"select * from auftraege
PHP-FAQ: Warum soll ich nicht SELECT * schreiben?
where Auftragsnummer = "".$_POST["Auftragsnummer"]."""),
PHP-FAQ: Prüfe importierte Parameter. Traue niemandem und Wie kann ich bösartigen Code in SQL-Abfragen unterbinden?.
Grüße aus Nürnberg
Tobias-
Hallo Tobias,
[code lang=mysql]
btw: lang=mysql gibt es nicht, hier wäre aber sowieso ein lang=php angebracht ggf. den Query nochmal in ein lang=sql schachteln.Hm. Stimmt wohl. Ist ja auch blödsinnig, bei einer Zeile aus der PHP-Datei einfach mal mysql anzugeben.
$Auftrag = mysql_fetch_array(mysql_query(
sowas ist _ganz_ schlecht - das erschwert die Fehlersuche drastisch. Du solltest dir angewöhnen, ersten den Query einer Variable zuzuweisen, dann mysql_query() aufzurufen (mit Fehlerbehandlung) und erst dann mysql_fetch_array() aufzurufen (wieder Fehlerbehandlung einbauen).Naja schon, aber dieser Teil war schon längst getestet, wird schon lange nur noch verwendet und ich dachte, dass extra in eine Variable speichern die Performance nicht gerade steigert. Ich habe es mal mit Variable geschrieben, aber danach habe ich es zusammengefasst.
"select * from auftraege
PHP-FAQ: Warum soll ich nicht SELECT * schreiben?Auf dieser Seite brauche ich alle Spalten, weil die Seite, von der ich das kopiert habe macht nichts anderes, als alles in ein Formular füllen, mit dem man die Werte ändern kann. Und da ich die Elemente des Arrays mit $Auftrag["Auftragsnummer"] und nicht mir $Auftrag[0] dürfte doch aus das mit der Reihenfolge keine Probleme machen, oder?
where Auftragsnummer = "".$_POST["Auftragsnummer"]."""),
PHP-FAQ: Prüfe importierte Parameter. Traue niemandem und Wie kann ich bösartigen Code in SQL-Abfragen unterbinden?.Also bei mir ist es so, dass solche Probleme nicht auftreten, weil da automatisch die entsprechenden Zeichen escaped werden.
Ich habe es ausprobiert, in die Fälter " und ' einzubinden und es funktioniert (sprich, die Zeichen werden bei einer folgenden Ausgabe wieder korrekt angezeigt).Danke für deine Bemühungen,
Tobias
-
-
-
-
-
-
-