Zahl in Tag Std Min und Sek umwandeln was ist falsch

[leif]

Hi ich hab gerde dieses Script geschieben und wollte die Zahl 10060 in Tag Std Min und Sek ausgeben.
Nur leider gehts das nicht wie ich mir vorgestellt habe, wass muss ich also anders machen?

<b id="TagTime">Gebäude</b> - <b id="StdTime">Gebäude</b>:<b id="MinTime">Gebäude</b>:<b id="SekTime">Gebäude</b>

<script language="Javascript">
<!--
var countdown = "10060";

function docount()
{

if (countdown > 0)
      {
          countdown--;
      }
      else
      {
          document.write('fertig');
      }

if(countdown > 86400){ tag = countdown / 86400; }else{ tag = 0; }
      if(countdown > 3600){ std = (countdown / 3600) - tag; }else{ std = 0; }
      if(countdown > 60){ min = (countdown / 60) - tag - std; }else{ min = 0; }
      if(countdown > 86400){ sek = countdown  - tag - std - sek; }else{ sek = 0; }

document.getElementById("TagTime").firstChild.nodeValue = tag;
      document.getElementById("StdTime").firstChild.nodeValue = std;
      document.getElementById("MinTime").firstChild.nodeValue = min;
      document.getElementById("SekTime").firstChild.nodeValue = sek;

window.setTimeout('docount()',1000);
}

docount();
//-->
</script>

[Cheatah]

Hi,

Hi ich hab gerde dieses Script geschieben und wollte die Zahl 10060 in Tag Std Min und Sek ausgeben.
Nur leider gehts das nicht wie ich mir vorgestellt habe, wass muss ich also anders machen?
var countdown = "10060";

wenn Du von einer Zahl redest, solltest Du auch eine verwenden. Dies ist ein String. Er ist größer als "100000000" und kleiner als "2"

<script language="Javascript">

ERROR: Required attribute "type" missing.

if(countdown > 86400){ tag = countdown / 86400; }else{ tag = 0; }

parseInt(), ein "if" brauchst Du nicht. Beschäftige Dich auch mit Modulo-Rechnung.

Cheatah

[Leif]

wie meinst du das Modulo-Rechnung

ich hab das jetzt so gemacht oder hast du nen besseren Vorschlag?

<b id="TagTime">Gebäude</b> - <b id="StdTime">Gebäude</b>:<b id="MinTime">Gebäude</b>:<b id="SekTime">Gebäude</b>

<script language="Javascript">
<!--
var countdown = "10060";

function docount()
{

if (countdown > 0)
      {
          countdown--;
      }
      else
      {
          document.write('fertig');
      }

tag = countdown / 86400;
      std = (countdown / 3600) - tag;
      min = (countdown / 60) - tag - std;
      sek = countdown  - tag - std - min;

tag = parseInt(tag)
      std = parseInt(std)
      min = parseInt(min)
      sek = parseInt(sek)

document.getElementById("TagTime").firstChild.nodeValue = tag;
      document.getElementById("StdTime").firstChild.nodeValue = std;
      document.getElementById("MinTime").firstChild.nodeValue = min;
      document.getElementById("SekTime").firstChild.nodeValue = sek;

window.setTimeout('docount()',1000);
}

docount();
//-->
</script>

[Rouven]

Hi,

mittels Modulo-Rechnung kannst du in einer Operation rausfinden, welchen Rest Zahl x bei Division durch Zahl y lässt:

1 mod 4 = 1
2 mod 4 = 2
3 mod 4 = 3
4 mod 4 = 0
5 mod 4 = 1
10 mod 4 = 2
...
60 mod 4 = 0

Der Modulo-Operator in JavaScript ist %
http://selfhtml.teamone.de/javascript/sprache/operatoren.htm#berechnung

Sekunden sind demnach
Zahl % <Anzahl der Sekunden eines Tages>

--> nach dem Schema kannst du das direkt ermitteln.

MfG
Rouven

[Sven Rautenberg]

Moin!

mittels Modulo-Rechnung kannst du in einer Operation rausfinden, welchen Rest Zahl x bei Division durch Zahl y lässt:

http://aktuell.de.selfhtml.org/tippstricks/programmiertechnik/zeitberechnung/index.htm

Damit sollte eigentlich jeder glücklich werden. Oder?

- Sven Rautenberg

[MatzeA]

Servus,

http://aktuell.de.selfhtml.org/tippstricks/programmiertechnik/zeitberechnung/index.htm

Damit sollte eigentlich jeder glücklich werden. Oder?

Den Tipp halte ich nur für Teilweise gut.
Denn Du gehst (soweit ich es gesehen habe) nicht in die Problematik Zeitverschibung und Winter / Sommerzeit ein.

Du verwendest auch kein Modul, z.B. Calendar, was mit den Verschiedenen Zeitzonen und der Zeitumstellung zurecht kommt.
Sehr schade wie ich finde.

Denn rein rechnerisch kann 23:00 - 1:00 3 Stunden sein.
Das sollte man nicht vergessen und kann in vielen Bereichen absolut wichtig sein.

Gruss Matze

[Sven Rautenberg]

Moin!

Den Tipp halte ich nur für Teilweise gut.

Der Tipp rechnet eine Sekundenzahl in eine menschenlesbare Zeitangabe um.

Denn Du gehst (soweit ich es gesehen habe) nicht in die Problematik Zeitverschibung und Winter / Sommerzeit ein.

Wenn ich X Sekunden habe, gibts keine Sommer/Winterzeit.

Denn rein rechnerisch kann 23:00 - 1:00 3 Stunden sein.

Ich rechne ja nicht mit Tageszeitangaben, sondern mit Sekunden.

Und 23:00 - 1:00 ist immer noch 22:00. Garantiert. Immer. Oder wahlweise auch 1320. Sekunden nämlich. :)

- Sven Rautenberg

[MatzeA]

Servus,

Wenn ich X Sekunden habe, gibts keine Sommer/Winterzeit.

Am besagtem Tag: könnte bei Uhrzeit: 02:59:59 wenige Sekunden durchaus ein Problem darstellen, und verschonen Dich nicht vor dem
Sommer Winterzeit Problem.

Und 23:00 - 1:00 ist immer noch 22:00. Garantiert. Immer. Oder wahlweise auch 1320. Sekunden nämlich. :)

Von 23:00 bis 01:00 des folge Tages sind es 1-3 Stunde je nachdem.

Gruss Matthias

[Sven Rautenberg]

Moin!

Wenn ich X Sekunden habe, gibts keine Sommer/Winterzeit.

Am besagtem Tag: könnte bei Uhrzeit: 02:59:59 wenige Sekunden durchaus ein Problem darstellen, und verschonen Dich nicht vor dem
Sommer Winterzeit Problem.

Ich habe ja aber auch keinerlei Tag. X Sekunden sind von Januar bis Dezember, Montags bis Freitags, morgens bis abends _immer_ genau diese X Sekunden. Oder umgerechnet auch eine Zahl von Minuten, Stunden und Tagen.

Und 23:00 - 1:00 ist immer noch 22:00. Garantiert. Immer. Oder wahlweise auch 1320. Sekunden nämlich. :)

Von 23:00 bis 01:00 des folge Tages sind es 1-3 Stunde je nachdem.

23:00 ist im Kontext des Artikels definiert als 23 Minuten, Null Sekunden. Oder eben 1380 Sekunden.
01:00 ist ebenso definiert als 1 Minute, Null Sekunden. Oder 60 Sekunden.

23:00 minus 01:00 ist also definiert als 1380 Sekunden minus 60 Sekunden. Ergebnis 1320 Sekunden. Oder 22:00 (22 Minuten, 0 Sekunden).

Dieser Zusammenhang gilt _immer_, egal ob Sommer- oder Winterzeit.

Denn es wird mit Zeit_räumen_ gerechnet, nicht mit Zeit_punkten_.

Und selbst wenn ich deine Zeitangaben als Stunden interpretiere, also 23 Stunden minus 1 Stunde, dann kommen immer noch 22 Stunden heraus.

Es ist etwas anderes, wenn ich 23:00:00 UHR habe und berechnen will, wieviel Zeit bis zu 01:00:00 Uhr des nächsten Tages vergeht. Da brauche ich das exakte Tagesdatum dazu, inklusive Jahresangabe und Zeitzonen, ansonsten ist diese Aufgabe nicht für alle Fälle lösbar.

Aber diese Problematik behandelt der Artikel nicht. Hier geht es wirklich nur um das ganz banale "Ein Rechenschritt ergab 13561 Sekunden - wieviel is'n das?". Und für einen Countdown (vgl. Ausgangsposting), der mit setTimeout() sekündlich runterzählt, diese Angabe aber gerne in einer lesbaren Form wiedergeben will, genau richtig.

- Sven Rautenberg

[MatzeA]

Servus,

Du solltest aber auf die Problematik hinweisen.
Es ist leider etwas irreführend, da Du im Sekunden Bereich Zeit berechnest und dann aus den Sekunden wieder zu Tag Stunde Minute kommst.

Allein, wenn jemand der Überzeugung sein sollte, dass 6:00 21600 Sekunden sind seit 0:00 liegt er mit einer möglichen Sommer Winterzeit umstellung falsch.

Gruss Matze

[Antje Hofmann]

Hallo Matze,

Du solltest aber auf die Problematik hinweisen.
Es ist leider etwas irreführend, da Du im Sekunden Bereich Zeit berechnest und dann aus den Sekunden wieder zu Tag Stunde Minute kommst.

Allein, wenn jemand der Überzeugung sein sollte, dass 6:00 21600 Sekunden sind seit 0:00 liegt er mit einer möglichen Sommer Winterzeit umstellung falsch.

Durchdenke bitte mal die folgende Interpretation deiner Aussagen:

Ich bin am 28.3. zwischen 0:00 und 5:00 Uhr online.
Nach Zeitpunkten berechnet sind das 5 Stunden. Da aber um 2:00 Uhr die Uhr um eine Stunde vorgestellt wird, beträgt die reale Onlinezeit 4 Stunden. Würde mein Provider nach deiner Aussage abrechnen, würde ich eine Stunde zuviel bezahlen.

Bin ich am 31.10 zwischen 0:00 und 5:00 Uhr online, gewinne ich diese Stunde zurück. Nach Zeitpunkten berechnet sind das auch hier wieder 5 Stunden. Da aber um 2:00 Uhr die Uhr um eine Stunde zurückgestellt wird, beträgt die reale Onlinezeit 6 Stunden. Würde mein Provider nach deiner Aussage abrechnen, würde ich eine Stunde zuwenig bezahlen.

Die Berücksichtigung von Sommer- und Winterzeit führt für diesen Sachverhalt sogar zu völlig unrichtigen Ergebnissen.

Ansonsten schau dir mal deine Telefonrechnung an. Wenn da steht 1:05:43 nimmst du doch auch nicht an, dass du um 1:05:43 Uhr telefoniert hast. Und die gebräuchliche Umwandlung in hh:mm:ss ist sehr viel besser lesbar und einschätzbar als 3943 s.

Viele Grüße

Antje

[MatzeA]

Servus,

Bin ich am 31.10 zwischen 0:00 und 5:00 Uhr online, gewinne ich diese Stunde zurück. Nach Zeitpunkten berechnet sind das auch hier wieder 5 Stunden. Da aber um 2:00 Uhr die Uhr um eine Stunde zurückgestellt wird, beträgt die reale Onlinezeit 6 Stunden. Würde mein Provider nach deiner Aussage abrechnen, würde ich eine Stunde zuwenig bezahlen.

Sorry, dann haben ich mich falsch ausgedrückt oder du mich nicht verstanden.
Genau darum geht es mir.
Es gibt wunderschöne Calendar Objekte, die man für Zeitberechnungen einsetzen kann, die dann auch zuverlässig diese Problematik erschlagen.

Die Berücksichtigung von Sommer- und Winterzeit führt für diesen Sachverhalt sogar zu völlig unrichtigen Ergebnissen.

Wir haben wohl völlig aneinandere vorbei geredet.
Das System gibt Dir beim Aufruf von Time um 01:00 01:00
um 06:00 06:00.
Wenn Du diese Zeitpunkte verwendest, herunter rechnest auf Sekunden und dann die Differenz beider Zeitpunkte berechnest (So habe ich Svens Beispiel verstanden, auch wenn er richtig sagt, man solle nicht auf Zeitpunkte bedingt Berechnen),
Dann bekommst Du unter umständen eine Zeitspanne, die um eine Stunde falsch ist.

Da liegt ja das Problem des ganzen. Wenn Du nun ein Online System hast, sollte es zumindest auch für die Deutschen Besucher die richtige Uhrzeit aneigen.

Folglich ist das System auf die Zeitzone GMT + 01:00 eingestelt.

Ansonsten schau dir mal deine Telefonrechnung an. Wenn da steht 1:05:43 nimmst du doch auch nicht an, dass du um 1:05:43 Uhr telefoniert hast. Und die gebräuchliche Umwandlung in hh:mm:ss ist sehr viel besser lesbar und einschätzbar als 3943 s.

Nichts anderes sage ich.

Wenn Du aber von 01:00 - 04:00 telefonierst am besagem von winter auf sommerzeit Tag...
Wie lange hast du dann telefoniert.
Un diwe lange telefonierst Du von 01:00 - 04:00 wenn man von sommerzeit wieder zurück auf winterzeit stellt?

Da liegt ja das Problem und nicht in der umrechnung.
Svens Beispiele hingegen erklären mir immer noch nicht, woher er eine Referezzeit hat, anhand der er differenzen Berechnen kann.

So wie ich ihn verstehe ist das mit der Zeitumstellung irrelevant für die differenz Berechnung. Theoretisch ja, solange man nicht über das Datum der Umstellung kommt.

Er meinte ja auch, dass er nicht mit Zeitpunkten rechnet.
Aber mit was rechnet er dann? Er muss ja einen Start und einen Stop punkt einrichten.
Wenn er einen Zähler verwendet, der im lediglich eine Zeitdauer liefert, ja dann ist das kein Problem.
Aber wie gibt er dann Startzeit und endzeit aus, ohne dass er hierbei auf die Nase fällt.

Klar die Differenz kann er dann anzeigen, gefahrlos über Stunden Minuten ja sogar Wochen und Monate.

Vieleicht auch grundsätzlich falsch verstanden, bei seinem Tip vermisse ich den Hinweis, dass es bei der Zeitberechnung ganz einfach unschöne Bedingungen zu bedenken gilt wie z.B. Zeitumstellung usw.

Ich zweifle nicht an der methodik wie er aus Sekunden Stunden und Minuten macht.

Gruss Matze

[Sven Rautenberg]

Moin!

Von 23:00 bis 01:00 des folge Tages sind es 1-3 Stunde je nachdem.

Wie kriegst du es hin, dass das nur eine Stunde dauert?
Wie kriegst du es hin, dass es drei Stunden dauert?

Bei mir sind das, ganz egal, ob Sommer- oder Winterzeitumstellung, ob Schaltjahr oder nicht, immer exakt zwei Stunden.

Schlechtes Beispiel gewählt. :) Du hättest den Zeitraum zwischen 1 Uhr und 4 Uhr nehmen sollen, _da_ hättest du _vielleicht_ Recht.

Aber auch nur "fast", denn zwischen 1 Uhr MEZ und 4 Uhr MEZ liegen selbstverständlich immer und überall 3 Stunden Zeit. Dass man zur Sommerzeitumstellung die Zeitzone wechselt, ist ein ganz anderes Problem.

- Sven Rautenberg

[MatzeA]

Servus,

Schlechtes Beispiel gewählt. :) Du hättest den Zeitraum zwischen 1 Uhr und 4 Uhr nehmen sollen, _da_ hättest du _vielleicht_ Recht.

Ich gebe dir Recht. :-)) Als alter, nein ich warte nicht bis 3:00 Morgens Muffel....

Aber auch nur "fast", denn zwischen 1 Uhr MEZ und 4 Uhr MEZ liegen selbstverständlich immer und überall 3 Stunden Zeit. Dass man zur Sommerzeitumstellung die Zeitzone wechselt, ist ein ganz anderes Problem.

Das ist ein Problem worauf man hinweisen sollte.
Und um solche Probleme bestmöglich zu umgehen bieten sich eben die Calendar bzw. Datums Funktionen prima an.

Ich würde nicht wie Du es gemacht hast meine Zeit auf Sekunden herunter Rechnen. Das führt nur zu Verwirrung und Problemen, wenn sich z.B. die Zeitzone ändert.

Gruss Matze

[Sven Rautenberg]

Moin!

Ich würde nicht wie Du es gemacht hast meine Zeit auf Sekunden herunter Rechnen. Das führt nur zu Verwirrung und Problemen, wenn sich z.B. die Zeitzone ändert.

Ich berechne ja auch keine Zeit auf Sekunden herunter, sondern eine Sekundenzahl zurück als Zeit.

Es geht, wie schon tausendmal erwähnt, eben gerade _nicht_ darum, die Differenz zwischen zwei kalendarischen Zeitpunkten zu ermitteln, sondern lediglich darum, eine - wie auch immer ermittelte - Zeitdauer in Sekunden benutzerfreundlich anzuzeigen.

Beispiel: Du willst deine Online-Zeit kontrollieren, damit du nicht mehr als 100 Stunden im Monat online bist. Also stoppst du die Zeit mit einer Stoppuhr und notierst dir die Werte.

Und weil dein Taschenrechner zu blöde ist, Zeiten zusammenzuaddieren, schreibst du dir dafür eben ein Programm.

Aus einem String "01:23:16" (eine Stunde, 23 Minuten, 16 Sekunden) die Sekundenzahl auszurechnen ist einfach. Aus mehrern solcher Strings die Sekunden auszurechnen und zu addieren, ist auch einfach. Aus dem Ergebnis wieder eine augenfreundliche Darstellung zu machen - dafür ist der Artikel da. Und bei dieser beispielhaften Aufgabenstellung kommt dann - je nach Benutzerwunsch - durchaus auch 135:45:57 raus (135 Stunden, 45 Minuten, 57 Sekunden). Also doch wieder zu lange gesurft. :)

- Sven Rautenberg

[Sven Rautenberg]

Moin!

Beispiel: Du willst deine Online-Zeit kontrollieren, damit du nicht mehr als 100 Stunden im Monat online bist. Also stoppst du die Zeit mit einer Stoppuhr und notierst dir die Werte.

Und weil dein Taschenrechner zu blöde ist, Zeiten zusammenzuaddieren, schreibst du dir dafür eben ein Programm.

Um noch einen obendraufzusetzen: Du kannst dir natürlich auch gleich ein kleines Skript für deinen lokalen PHP-Webserver schreiben, welches zwei Buttons "Start" und "Stop" hat und sich jeweils die Uhrzeit merkt, zu der man sie klickt.

Und die Differenz zwischen den beiden Zeiten ist dann die Onlinezeit. Und damit sowas problemfrei berechnet werden kann, nimmt man am einfachsten.... den Unix-Timestamp! Der ist nämlich schon in Sekunden, und wird auch jede Sekunde um 1 inkrementiert, egal ob Sommer- oder Winterzeit. Damit kriegt man also hundertprozentig exakt die Differenz zwischen den beiden Zeitpunkten raus - und hat dann Sekunden, die man aufaddieren kann, und die man irgendwann eben vernünftig lesbar ausgeben will.

Aus dem Ergebnis wieder eine augenfreundliche Darstellung zu machen - dafür ist der Artikel da. Und bei dieser beispielhaften Aufgabenstellung kommt dann - je nach Benutzerwunsch - durchaus auch 135:45:57 raus (135 Stunden, 45 Minuten, 57 Sekunden). Also doch wieder zu lange gesurft. :)

- Sven Rautenberg

[MatzeA]

Servus,

genau das ist falsch.

Wenn Du Dir vom (ich kenn nun das Datum nicht genau) 15.4.04
0:45 Beispielsweise den Timestamp geben lässt wird diese Differenz  vom Jahre 197x sonstwas bis 1:00 (je nach Systemeinstellung) Winterzeit ausgegeben. Gegebenfalls in Sekunden.

Um 02:00 wird die Uhrzeit auf Sommerzeit umgestellt.
Dann wird aus 02:00 03:00. Damit liefert dir der timestamp entsprechende Zahl. Die differenz sind dann 2 Stunden.
-> Muss aber zugeben, ich weiss nicht genau, ob nun jedes Unix so doof ist, oder ob manches Unix tatsächlich in der lage ist vernünftige Werte zu liefern.

In diesem Fall warst Du aber von 01:00 - 03:00 Online
theoretisch 2 Stunden laut Deiner Berechung. In Wirklichkeit warst Du aber 1 Stunde online. Bei mder Telekom bin ich mir nicht sicher, aber ein anständiges Unternehmen würde da auch nicht mehr als 2 Stunde berechnen.

Oder reden wir immer noch Meilenweit aneinanderer vorbei?

Gruss Matze

[Sven Rautenberg]

Moin!

genau das ist falsch.

Oh, Vorsicht mit so absoluten Aussagen. :)

Wenn Du Dir vom (ich kenn nun das Datum nicht genau) 15.4.04 0:45 Beispielsweise den Timestamp geben lässt wird diese Differenz  vom Jahre 197x sonstwas bis 1:00 (je nach Systemeinstellung) Winterzeit ausgegeben. Gegebenfalls in Sekunden.

Stimmt nicht ganz.

Ausgangspunkt für den Unix-Timestamp ist der 1.1.1970, 0:00. Soweit richtig. Da man aber erkannt hat, das es auf der Welt sowas wie Zeitzonen gibt, die die Zeitberechnung komplizierter machen, ist die ganz präsize Zeitangabe eben "1.1.1970, 0:00 UTC". Also Greenwich-Zeit.

Merke: In der Zeitzone UTC gibt es keine Sommerzeit. Und beim Unix-Timestamp, der auf diesem fixen Zeitpunkt basiert, kommt jede Sekunde eine Sekunde dazu, ohne irgendwelche Sprünge. Kein Unix-Timestamp existiert irgendwie doppelt oder ergibt zwei verschiedene Zeitpunkte aufgrund von Sommerzeitumstellung.

Die Berechnung eines Unix-Timestamp, basierend auf der lokalen Zeit, bezieht logischerweise die lokale _Zeitzone_ mit ein. Deshalb ist es vollkommen egal, ob sich die lokale Zeitzone ändert - diese Änderung fließt automatisch mit in die Berechnung ein.

Deshalb wird bei der Zeitumstellung von MEZ zu MESZ diese Stunde Differenz automatisch berücksichtigt.

Um 02:00 wird die Uhrzeit auf Sommerzeit umgestellt.
Dann wird aus 02:00 03:00. Damit liefert dir der timestamp entsprechende Zahl. Die differenz sind dann 2 Stunden.

Probiere es bitte selbst aus:

<?php

$mk = mktime (01,10,00, 3,28,2004);
echo "<br>Time: $mk<br>";
echo "UTC: ".gmdate("M d Y H:i:s",$mk)."<br>";
echo "local: ".date("M d Y H:i:s",$mk)."<br>";

$gk = gmmktime(01,10,00, 3,28,2004);
echo "<br>Time: $gk<br>";
echo "UTC: ".gmdate("M d Y H:i:s",$gk)."<br>";
echo "local: ".date("M d Y H:i:s",$gk)."<br>";

?>

Zuerst wird ein Unix-Timestamp, basierend auf der lokalen Zeitzone (bei mir: MEZ) generiert für den 28.3.2004, 01:00:00 Uhr. Da kommt bei mir 1080432600 raus.

Dieser Timestamp wird dann einmal als UTC und als lokale Zeitzone wiedergegeben:
UTC: Mar 28 2004 00:10:00
local: Mar 28 2004 01:10:00

Logisch: Wenn es bei und 1:10 Uhr ist, ist es bei uns 1:10 Uhr, und in London/Greenwich ist es erst 0:10 Uhr.

Dann wird der Unix-Timestamp basierend auf der UTC-Zone für 1:10 Uhr desselben Tages gebildet. Ergibt bei mir (und auch bei dir (sollte zumindest)) 1080436200.

Bemerke, dass dieser Zeitstempel genau 3600 größer ist, als der erste Zeitstempel. Logisch: Der erste Zeitstempel war 0:10 UTC, dieser ist 1:10 UTC, also eine Stunde (oder 3600 Sekunden) später.

Die Rückverwandlung in lesbare Zeit ergibt:
UTC: Mar 28 2004 01:10:00
local: Mar 28 2004 03:10:00

Wie man sieht: Die lokale Zeitzone hat zu diesem Zeitpunkt bereits Sommerzeit, die Differenz ist also jetzt zwei Stunden im Vergleich zu UTC. Weil: Wenn es 1:10 UTC ist, wäre es bei MEZ 2:10. Da um 2:00 MEZ aber die Sommerzeit beginnt (Uhren eine Stunde vorstellen), ist es um 2:10 MEZ bereits 3:10 MESZ.

An jedem anderen Tag außer dem 28.3.2004 würden die Differenzen zwischen lokal und UTC bei beiden Beispielen identisch sein.

-> Muss aber zugeben, ich weiss nicht genau, ob nun jedes Unix so doof ist, oder ob manches Unix tatsächlich in der lage ist vernünftige Werte zu liefern.

Unix ist schon sehr lange in der Lage, vernünftige Werte zu liefern - im Gegensatz zu Windows. Wenn obiges Programm also nicht das macht, was ich beschrieben habe, dann war vielleicht Windows im Spiel.

Für Unix wird empfohlen, dass die Systemuhr auf UTC läuft. Außerdem ist die Zeitzone konfiguriert. Aus diesen beiden Informationen kann man jederzeit die lokale Zeit berechnen. Und es gibt auch keine Probleme mit dem Erstellungs- und Änderungsdatum von Dateien, wenn diese auf UTC basierend abgelegt sind. Das läßt sich in einem Schritt auf die lokale Zeit umrechnen und ausgeben.

Windows läßt die Systemuhr auf lokaler Zeit laufen, und speichert Änderungsdaten von Dateien basierend auf lokaler Zeitzone. Das ist insofern schlecht, weil man eben beim Zurückstellen der Sommerzeit zweimal den Zeitraum von 2 bis 3 Uhr auf der lokalen Uhr hat. Wie soll man das umrechnen in eine andere Zeitzone?

In diesem Fall warst Du aber von 01:00 - 03:00 Online
theoretisch 2 Stunden laut Deiner Berechung. In Wirklichkeit warst Du aber 1 Stunde online. Bei mder Telekom bin ich mir nicht sicher, aber ein anständiges Unternehmen würde da auch nicht mehr als 2 Stunde berechnen.

Ok, rechnen wir das mal mit PHP nach. Am 28.3.2004 wird um 2 Uhr die Uhr auf 3 Uhr vorgestellt. Wenn ich also von 1:00 Uhr bis 3:01 Uhr (nur um sicherzugehen) online wäre, dann wären das basierend auf Zahlen 2:01 Stunden, basierend auf echter Zeit aber nur 1:01 Stunden.

<?php
$mk1 = mktime (01,00,00, 3,28,2004);
$mk2 = mktime (03,01,00, 3,28,2004);
echo "<br>Time1: $mk1<br>";
echo "local: ".date("M d Y H:i:s",$mk1)."<br>";
echo "<br>Time2: $mk2<br>";
echo "local: ".date("M d Y H:i:s",$mk2)."<br>";

$diff = $mk2-$mk1;
echo "diff: $diff";
?>

Ergibt:
Time1: 1080432000
local: Mar 28 2004 01:00:00

Time2: 1080435660
local: Mar 28 2004 03:01:00
diff: 3660

3660 Sekunden sind genau 1 Stunde und 1 Minute. Voila! Nichts anderes hätte eine parallel mitlaufende Stoppuhr gezählt - die ja auch nur Sekunden aufaddiert.

Oder reden wir immer noch Meilenweit aneinanderer vorbei?

Du verstehst den Ansatz des Artikels nicht bzw. vermischst ihn mit einem anderen Thema, welches damit nicht das geringste zu tun hat - außer dass es bei beidem um Sekunden geht. Das ist das Problem.

- Sven Rautenberg

[MatzeA]

Servus,

gut jetzt ist es klar und soweit verständlich.
Ich hab dich zumindest teilweise falsch verstanden.

Tortzdem würde Ich in Deinem Artikel gegebenfalls die Problematik hierüber und auch die Empfehlung auf UTC als Systemzeitzone einfügen.
Ansonsten bin ich mir sicher, tappt irgendein Newbie in diese Stolperfalle.

Gruss Matze

[Sven Rautenberg]

Moin!

gut jetzt ist es klar und soweit verständlich.
Ich hab dich zumindest teilweise falsch verstanden.

Gut, dann wäre das geklärt.

Tortzdem würde Ich in Deinem Artikel gegebenfalls die Problematik hierüber und auch die Empfehlung auf UTC als Systemzeitzone einfügen.
Ansonsten bin ich mir sicher, tappt irgendein Newbie in diese Stolperfalle.

Da mein Artikel das Thema "wie bilde ich die Differenz in Sekunden zweier bekannter Zeitpunkte" nicht behandelt, sehe ich den Grund nicht - das Thema _ist_ komplex und würde diesen ohnehin für "Tipps&Tricks" zu langen Artikel unnötig aufblähen. Ich verweise aber gerne auf einen Artikel von dir zu diesem Thema, solltest du einen schreiben. :)

- Sven Rautenberg

[MatzeA]

Servus,

Ich verweise aber gerne auf einen Artikel von dir zu diesem Thema, solltest du einen schreiben. :)

Du bist so fieeees.

Ja fut weil ich e grad wieder diverse Zeitprobleme bearbeite könnte man sich das ja überlegen.
Wohin soll man es Posten?

Gruss Matze

[Sven Rautenberg]

Moin!

Ich verweise aber gerne auf einen Artikel von dir zu diesem Thema, solltest du einen schreiben. :)

Du bist so fieeees.

Ich weiß. Aber es wirkt ja.

Ja fut weil ich e grad wieder diverse Zeitprobleme bearbeite könnte man sich das ja überlegen.
Wohin soll man es Posten?

Sofern du dich kurzfassen und mit einer Formulareingabe rumschlagen willst (so schlimm ist die nicht): http://aktuell.de.selfhtml.org/tippstricks/beitrag.htm.

Wenn du der Meinung bist, dass du das Thema nicht auf einer Seite auf den Punkt bringen kannst, oder auch gerne zur "Geschichte der Zeit" abschweifen willst: http://aktuell.de.selfhtml.org/artikel/beitrag.htm.

Bedenke aber, dass du in beiden Fällen durch unsere QA durch mußt, die sich im wesentlichen "nur" damit beschäftigt, ob du in ganzen Sätzen verständlich formulieren konntest, was du dir als Thema vorgenommen hast. Sofern sich keiner drum reißt, werde ich das sein. :)

- Sven Rautenberg

[MatzeA]

Servus,

Bedenke aber, dass du in beiden Fällen durch unsere QA durch mußt, die sich im wesentlichen "nur" damit beschäftigt, ob du in ganzen Sätzen verständlich formulieren konntest, was du dir als Thema vorgenommen hast. Sofern sich keiner drum reißt, werde ich das sein. :)

Du meinst vermutlich QM oder den QP gegebenfalls auch die QK bzw. QC aber nicht QA. ;-)

Ihr wollt auch noch ganze Sätze. Also einem geschenkten Gaul schaut man nicht ins Maul.
Da wird vermutlich nie was draus werden, dass auch nur ein einziger Artikel von mir veröffentlicht wird.

Obwohl mir grad 2 -3 kurzgeschichten zum Thema IT Leben erleichtern einfallen.

Gruss Matze

[Siechfred]

Siehe Titel und [pref:t=75009&m=432116].
Ein anderer Name macht es nicht gerade besser.

Siechfred