PHP: Datumsberechnung mit Sommerzeit/Winterzeit

[Jan Wa]

Hallo!

Ich will mit PHP die sieben nächsten Tage ausgeben, ausgehend vom gestrigen Tag.

Ich mache das aktuell so:

$i = -1;
$max = 6;
$cdate = strtotime('today midnight');
for ( $i=$min; $i<=$max; $i++ ) {
print $cdate + (86400 * $i);
}

Wenn ich das heute starte, gibt es mir den 30.10. zwei mal aus, was an der Umschaltung von Sommerzeit auf Winterzeit liegt.

Nun dachte ich, ich suche mir eine PHP-Funktion zur Datumsberechnung, die wird das schon beachten mit der Umstellung.

Habe dann die Ausgabezeile im obigen Skript durch folgendes ersetzt:

print DateTimeImmutable::createFromFormat('U', $cdate)->modify($i .' day')->format('U');

Doch selbes Ergebnis; ich hatte gehofft anhand der Servereinstellungen oder was auch immer, erkennt PHP, dass ich in einem Land lebe, wo man die Uhrzeitumstellung beachten muss.

Kennt sich jemand aus, ob ich noch einen Parameter angeben kann bzw. wie ich das Problem gelöst bekomme?

Danke

[Google weiß alles]

Hallo!

Ich will mit PHP die sieben nächsten Tage ausgeben, ausgehend vom gestrigen Tag.

mktime() hilft Dir.

<?php
echo date("Y-m-d", mktime(0, 0, 0, 10, 27, 2016)), "\n";
echo date("Y-m-d", mktime(0, 0, 0, 10, 28, 2016)), "\n";
echo date("Y-m-d", mktime(0, 0, 0, 10, 29, 2016)), "\n";
echo date("Y-m-d", mktime(0, 0, 0, 10, 30, 2016)), "\n";
echo date("Y-m-d", mktime(0, 0, 0, 10, 31, 2016)), "\n";
echo date("Y-m-d", mktime(0, 0, 0, 10, 32, 2016)), "\n";
echo date("Y-m-d", mktime(0, 0, 0, 10, 33, 2016)), "\n";
echo date("Y-m-d", mktime(0, 0, 0, 10, 34, 2016)), "\n";

Schau auf die Tage :-)

Ergebnis:

2016-10-27
2016-10-28
2016-10-29
2016-10-30
2016-10-31
2016-11-01
2016-11-02
2016-11-03

[Jan Wa]

Hallo!

Ich will mit PHP die sieben nächsten Tage ausgeben, ausgehend vom gestrigen Tag.

mktime() hilft Dir.

Ok, nicht "sauber", aber funktioniert. Auch beim Jahreswechsel :)

Danke!

[Tagwächter]

Ok, nicht "sauber",

Doch! Das gezeigte Verhalten ist dokumentiert. Es wird also kein Zufall oder Bug ausgenutzt.

[1unitedpower]

Ok, nicht "sauber",

Doch!

Dir selber unter anderem Namen Recht zu geben ist nicht gerade die feine Art. Unsere Charta ist ziemlich eindeutig was Sockenpuppen betrifft. Wir dulden das Verhalten bei dir schon eine ganze Weile, weil du bisher nicht übermäßig negativ damit aufgefallen bist. Das ist hier nun anders, gewöhne dir diesen Stil bitte gar nicht erst an. Bleib doch zumindest pro Thread bei einem Namen.

[Tagwächter]

Ok, nicht "sauber",

Doch!

Dir selber unter anderem Namen Recht zu geben ist nicht gerade die feine Art.

Wenn es mir darum gegangen wäre, m"ir selber unter anderem Namen Recht zu geben", dann hätte ich das Sicherheit weitaus geschickter angefangen - und vor allem nicht einen Namen gewählt, bei dem eine Vielzahl von Lesern im Bruchteil von Millisekunden genau den selben Zusammenhang herstellt wie bei den Namen "Pontius" und "Pilatus".

Und da letztes offensichtlich ist frage ich mich, was Dein Vorhalten, es sei mir darum gegangen, m"ir selber unter anderem Namen Recht zu geben", wohl (mal wieder!) soll. Denn entweder ist Deine Vorhaltung mutwillig oder aber Deine unzweifelhaft vorhandene Intelligenz ist sehr ungleichmäßig auf verschiedene Gebiete verteilt. Wobei natürlich ersteres unmittelbar aus dem zweiten folgen kann.

Was da für ein Name drin steht erscheint zwar willkürlich, ist aber vorliegend eine Frage des benutzten Browsers und auch des Gerätes. Ich ändere nur selten das Formularfeld - und nachträglich kann man den Namen nicht ändern (auch wenn das Bearbeiten- Formular anderes vormacht) - teste das oder frag CK wenn Du es nicht glaubt. Also spielt der Zufall hier durchaus Rolle. Denn welchen Browser auf welchen Gerät ich gerade benutze hängt davon ab was ich parallel erledige.

[1unitedpower]

Unser Toleranzbereich bei Sockenpuppen ist äußerst strapazierfähig. Hier hast du meiner Meinung nach über die Stränge geschlagen, ich habe dir erklärt warum. Ob es nun von dir beabsichtigt war oder nicht, es verzerrt die Diskussion, wenn du unter verschiedenen Pseudonymen an der selben Diskussion teilnimmst. Das ist in meinen Augen kein schwerer Verstoß, deshalb habe ich nur verbal interveniert. Nimm es als die schwächste Form der Moderation und versuche es in Zukunft besser zu machen.

[dedlfix]

Tach!

print $cdate + (86400 * $i);

Das ist das Problem. Wenn du immer 24 Stunden dazurechnest, kann auch die Ausgabefunktion nichts reißen. Wenn der Tag 25 Stunden hat, ist nach 24 Stunden immer noch derselbe Tag, wenn man da nicht die eine Stunde gegenkorrigiert.

Nun dachte ich, ich suche mir eine PHP-Funktion zur Datumsberechnung, die wird das schon beachten mit der Umstellung.

Ja, wenn man beispielsweise die Berechnung strtotime() überlässt: strtotime('+1 day', $timestamp)

Doch selbes Ergebnis; ich hatte gehofft anhand der Servereinstellungen oder was auch immer, erkennt PHP, dass ich in einem Land lebe, wo man die Uhrzeitumstellung beachten muss.

Das Problem liegt nicht bei PHP, sondern an deinen festen 24 Stunden, die die Stunde Unterschied nicht beachten.

Kennt sich jemand aus, ob ich noch einen Parameter angeben kann bzw. wie ich das Problem gelöst bekomme?

Alternativ zu strtotime() kannst du auch mit 12 Uhr Mittags anfangen, wenn du nur am Datum interessiert bist. Dann schwankt das im Laufe des Jahres um eine Stunde am Mittag und da ist dann immer noch dasselbe Datum.

dedlfix.

[Jan Wa]

Tach!

print $cdate + (86400 * $i);

Das ist das Problem. Wenn du immer 24 Stunden dazurechnest, kann auch die Ausgabefunktion nichts reißen. Wenn der Tag 25 Stunden hat, ist nach 24 Stunden immer noch derselbe Tag, wenn man da nicht die eine Stunde gegenkorrigiert.

Jaja, das habe ich dann bemerkt und es deshalb mit der PHP-eingebauten Funktion

DateTimeImmutable::createFromFormat('U', $cdate)->modify($i .' day')->format('U');

probiert, da ich dachte, diese beachtet das. Aber das hatte auch nicht funktioniert und deshalb diese Anfrage von mir hier.

Vielen Dank!

[dedlfix]

Tach!

Jaja, das habe ich dann bemerkt und es deshalb mit der PHP-eingebauten Funktion

DateTimeImmutable::createFromFormat('U', $cdate)->modify($i .' day')->format('U');

Also so gehts:

$max = 6;
$date = new DateTime('today midnight');

for ($i=0; $i<=$max; $i++ ) {
    $date->modify("+1 day");
    echo $date->format('Y-m-d H:i:s'), "\n";
}

Zeitzone ist bei mir in der php.ini richtig gesetzt.

dedlfix.

[TS]

Hallo und guten Morgen,

Alternativ zu strtotime() kannst du auch mit 12 Uhr Mittags anfangen, wenn du nur am Datum interessiert bist. Dann schwankt das im Laufe des Jahres um eine Stunde am Mittag und da ist dann immer noch dasselbe Datum.

Wenn der Request immer beim selben Server landet...

Da habe ich selbst bei Google schon nette Sachen erlebt. Die hatten wohl bestimmte Skripte einfach so über ihre Standorte in den USA verteilt und hatten keinen Ableich drin, in welcher Zeitzone die gerade laufen. Die Requests wurden (vermutlich zur Lastverteilung) aber brav über die Server verteilt und das war's dann ;-P

Grüße
TS

[MudGuard]

Hi,

Die hatten wohl bestimmte Skripte [...] und hatten keinen Ableich drin

Die Scripte sind also nie gestorben? ;-)

cu,
Andreas a/k/a MudGuard

[TS]

Hallo und guten Morgen,

Die hatten wohl bestimmte Skripte [...] und hatten keinen Ableich drin

Die Scripte sind also nie gestorben? ;-)

Sagt der Bayerische Angler zum Gendarmen: "bleibst aussi Büerscherl, wia hoam da a Laich"

Grüße
TS

[dedlfix]

Tach!

Wenn der Request immer beim selben Server landet...

... ist es auch vom Zufall abhängig, wenn man die Zeitzone nicht selbst einstellt.

dedlfix.

[TS]

Hallo und guten Abend,

Eine von mehreren Möglichkeiten:

mit date() und time() kannst DU feststellen, ob er der Server überhaupt Sommerzeit unterstützt und ob er aktuell einen Zeit-Offset benutzt und wie groß der ist.

Lass Dir die Zeit in UTC ausgeben und vergleiche sie mit der aktuell eingestellten, die time() liefert.

Grüße
TS

[dedlfix]

Tach!

Eine von mehreren Möglichkeiten:

mit date() und time() kannst DU feststellen, ob er der Server überhaupt Sommerzeit unterstützt und ob er aktuell einen Zeit-Offset benutzt und wie groß der ist.

Jeder Server unterstützt das, der die Zeitzonendatenbank geladen hat. Und man muss die Werte nicht feststellen, man kann die Zone festlegen.

dedlfix.

[TS]

Hallo und guten Abend,

Jeder Server unterstützt das, der die Zeitzonendatenbank geladen hat. Und man muss die Werte nicht feststellen, man kann die Zone festlegen.

In welcher Zeitzone speichert ein Server denn Daten, wenn keine festgelegt ist?
Und woher weiß mein Skript dann, dass keine festgelegt ist?
Und woher weiß es, welche es für die bereits vorhandenen Daten benutzen muss, wenn ich in meinem Skript willkürlich eine festlege?

Grüße
TS

[dedlfix]

Tach!

In welcher Zeitzone speichert ein Server denn Daten, wenn keine festgelegt ist?

Speichern ist deine Angelegenheit. Berechnen meinst du sicher, wenn man die Nicht-UTC-Funktionen (ohne gm*) nimmt. (Wie der objektorientierte DateTime-Teil arbeitet habe ich keine Erfahrung.)

Siehe date_default_timezine_get().

Und woher weiß mein Skript dann, dass keine festgelegt ist?

Beantwortet sich aus dem Link.

Und woher weiß es, welche es für die bereits vorhandenen Daten benutzen muss, wenn ich in meinem Skript willkürlich eine festlege?

Du sagst es ihm. Vermutlich hast du PHP-üblich mit Timestamps gearbeitet, das sind immer die Anzahl der Sekunden seit 1.1.1970 und UTC (ohne Schaltsekunden). mktime() hat das für dich nach UTC umgerechnet und date() wieder zurück, wenn du beispielsweise diese Funktionen verwendet hast. Wenn du dich bisher nicht um die Zeitzonenenstellung gekümmert hast, dann ist da unter Umständen ein falscher UTC-Wert entstanden, den es auf dieselbe falsche Weise wieder zurückgerechnet hat, wobei der Fehler nicht auffiel. Da hst du dann genauso Pech und Reparaturbedarf wie wenn du mit falscher Zeichenkodierung Datenbankzugriffe durchführst. Apropos Datenbank, die hat natürlich auch eine Zeitzoneneinstellung.

dedlfix.

[TS]

Hallo und guten Morgen,

Apropos Datenbank, die hat natürlich auch eine Zeitzoneneinstellung.

Genau darum ging es mir!

Bevor ich mit vorhandenen Daten arbeite, muss ich erstmal feststellen, ob die auch richtig abgespeichert wurden. Und dann sollten Datenbank und Skripte tunlichst keine unterschiedlichen Einstellungen haben.

Grüße
TS

[pl]

Hallo!

Ich will mit PHP die sieben nächsten Tage ausgeben, ausgehend vom gestrigen Tag.

Ich mache das aktuell so:

$i = -1;
$max = 6;
$cdate = strtotime('today midnight');
for ( $i=$min; $i<=$max; $i++ ) {
print $cdate + (86400 * $i);
}

Wenn ich das heute starte, gibt es mir den 30.10. zwei mal aus, was an der Umschaltung von Sommerzeit auf Winterzeit liegt.

Nein, das liegt an dem Unfug, Tagesberechnungen über Sekunden durchzuführen. Aus diesem Grund gibt es ja auch nur eine Datumsgrenze auf dieser Welt und nicht 86400 was auf dem Äquator rund alle zwei Kilometer sein müsste.

MfG

[Christian Kruse]

Hallo pl,

keine Ahnung, warum du hier negativ bewertet wurdest, du hast…

Nein, das liegt an dem Unfug, Tagesberechnungen über Sekunden durchzuführen.

… völlig recht.

LG,
CK

[dedlfix]

Tach!

keine Ahnung, warum du hier negativ bewertet wurdest, du hast…

Nein, das liegt an dem Unfug, Tagesberechnungen über Sekunden durchzuführen.

… völlig recht.

Erschloss sich dir der nachfolgende Satz, also warum solche fehlerhaften Berechnungen der Grund sein sollen, dass es nur eine Tagesgrenze gibt?

dedlfix.

[Christian Kruse]

Hallo dedlfix,

keine Ahnung, warum du hier negativ bewertet wurdest, du hast…

Nein, das liegt an dem Unfug, Tagesberechnungen über Sekunden durchzuführen.

… völlig recht.

Erschloss sich dir der nachfolgende Satz, also warum solche fehlerhaften Berechnungen der Grund sein sollen, dass es nur eine Tagesgrenze gibt?

Nein, es hat mich auch nicht interessiert. Aber ich würde dann eher nachfragen, was gemeint ist.

LG,
CK

[dedlfix]

Tach!

Erschloss sich dir der nachfolgende Satz, also warum solche fehlerhaften Berechnungen der Grund sein sollen, dass es nur eine Tagesgrenze gibt?

Nein, es hat mich auch nicht interessiert. Aber ich würde dann eher nachfragen, was gemeint ist.

Hab ich schon so oft gemacht und keine zufriedenstellenden Antworten bekommen.

Die Bewertung bezieht sich ja auch nicht nur auf den einen richtigen Satz, sondern auf die Antwort als Gesamtwerk. Zudem ist es nicht pauschal Unfug. Man kann das durchaus als Abkürzung verwenden, wenn man die Begleitumstände berücksichtigt. Wenn man die Mitte des Tages nimmt, hat es zum Beispiel keine negativen Auswirkungen auf das Ergebnis - so lange, wie in diesem Fall, die Uhrzeit irrelevant ist.

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Erschloss sich dir der nachfolgende Satz, also warum solche fehlerhaften Berechnungen der Grund sein sollen, dass es nur eine Tagesgrenze gibt?

Nein, es hat mich auch nicht interessiert. Aber ich würde dann eher nachfragen, was gemeint ist.

Hab ich schon so oft gemacht und keine zufriedenstellenden Antworten bekommen.

Na gut, da hast du recht.

Die Bewertung bezieht sich ja auch nicht nur auf den einen richtigen Satz, sondern auf die Antwort als Gesamtwerk.

Du hast mich glaube ich missverstanden, du musst dich nicht rechtfertigen :-) ich habe es nur einfach wirklich nicht verstanden, weil die Antwort für mich nicht schlecht war. Das kann ich inzwischen allerdings nachvollziehen.

Zudem ist es nicht pauschal Unfug.

Darum ging es im OP nicht :)

LG,
CK

[Gunnar Bittersmann]

@@dedlfix

Zudem ist es nicht pauschal Unfug. Man kann das durchaus als Abkürzung verwenden, wenn man die Begleitumstände berücksichtigt.

Wenn man einen Tag dazurechnen möchte, möchte man einen Tag dazurechnen, nicht 86400 Sekunden.

Wenn man die Mitte des Tages nimmt, hat es zum Beispiel keine negativen Auswirkungen auf das Ergebnis - so lange, wie in diesem Fall, die Uhrzeit irrelevant ist.

Oder solange, bis jemand auf die Idee kommt, dass die Uhren in der Nacht umgestellt werden, sondern tagsüber.

LLAP 🖖

[TS]

Hallo und guten Morgen,

Wenn man einen Tag dazurechnen möchte, möchte man einen Tag dazurechnen, nicht 86400 Sekunden.

Wenn man die Mitte des Tages nimmt, hat es zum Beispiel keine negativen Auswirkungen auf das Ergebnis - so lange, wie in diesem Fall, die Uhrzeit irrelevant ist.

Oder solange, bis jemand auf die Idee kommt, dass die Uhren in der Nacht umgestellt werden, sondern tagsüber.

... oder ein armes Büroschweinchen die aktuelle Zeit und das Datum einer anderen Zeitzone als seiner bestimmen muss.

Grüße
TS

[dedlfix]

Tach!

Oder solange, bis jemand auf die Idee kommt, dass die Uhren in der Nacht umgestellt werden, sondern tagsüber.

Oh, schau mal da drüben ein Irr-Elefant, auf den jemand YAGNI geschrieben hat.

dedlfix.

[Tagwächter]

Oder solange, bis jemand auf die Idee kommt, dass die Uhren [von mir ergänzt:]nicht in der Nacht umgestellt werden, sondern tagsüber.

Oh, schau mal da drüben ein Irr-Elefant, auf den jemand YAGNI geschrieben hat.

Och. Gibt genügend Diktatoren mit merkwürdigen Ideen. Auch in Deutschland kann man vermuten, dass die Regierung sich nicht aus den hellsten Köpfen zusammensetzt.

[TS]

Hallo und guten Tag,

Och. Gibt genügend Diktatoren mit merkwürdigen Ideen. Auch in Deutschland kann man vermuten, dass die Regierung sich nicht aus den hellsten Köpfen zusammensetzt.

Ich warte schon ständig auf die Meldung über alle Ticker und Kanäle:
"Die Türken stehen kurz vor Wien. Ab 5:45 wird zurückgeschossen..."

Grüße
TS

[Tagwächter]

Ich warte schon ständig auf die Meldung über alle Ticker und Kanäle:
"Die Türken stehen kurz vor Wien. Ab 5:45 wird zurückgeschossen..."

Naja. Momentan würde ich eine ähnliche Meldung eher aus der Türkei erwarten, die ja, folgt man Erdogan, von bösen Feinden umzingelt ist.

[Gunnar Bittersmann]

@@dedlfix

Oder solange, bis jemand auf die Idee kommt, dass die Uhren in der Nacht umgestellt werden, sondern tagsüber.

Oh, schau mal da drüben ein Irr-Elefant, auf den jemand YAGNI geschrieben hat.

Wie TS schlau erkannt hat, werden die Uhren ein paar Längengrade östlich oder westlich die Uhren bereits für uns tagsüber umgestellt.

LLAP 🖖

[Gunnar Bittersmann]

@@dedlfix

YAGNI

Dazu hab ich gestern erst gelesen:

“Don’t write code that guesses the future, arrange code so you can adapt to the future when it arrives.” —Sandi Metz

Der zweite Teil wird oft vergessen.

LLAP 🖖

[dedlfix]

Tach!

“Don’t write code that guesses the future, arrange code so you can adapt to the future when it arrives.” —Sandi Metz

Der zweite Teil wird oft vergessen.

Wäre hier sehr einfach durch eine Änderung der Stunde von Mittag auf eine andere Stunde mit ausreichendem Abstand zum Umstellungszeitpunkt zu erledigen.

Was ist eigentlich mit dem Fall, dass in der Zukunft entschieden werden könnte, vom jetzigen Zeitzählsystem wegzugehen und zum Beispiel auf Internetzeit umzustellen? Wenn du schon mit Zukunftssicherheit daherkommst, dann bitte auch alle möglichen Fälle und nicht nur einen einzelnen berücksichtigen ... oder am besten YAGNI und rankommen lassen, was wirklich der Fall ist.

Um das aber nochmal klarzustellen, ich würde auch nicht solch einen auf Sekunden basierten Code schreiben, weil der einfach nicht expressiv genug ist, nicht direkt auszudrücken in der Lage ist, was gemeint ist. Aus der Sekundenanzahl geht nur dann hervor, dass (eigentlich) ein Tag gemeint ist, wenn man weiß, dass es 86400 sind. '+1 day' ist da wesentlich einfacher zu lesen. Das ändert aber nichts daran, dass man mit dem 86400er-Code auch fehlerfrei zum Ziel kommen kann.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Wäre hier sehr einfach durch eine Änderung der Stunde von Mittag auf eine andere Stunde mit ausreichendem Abstand zum Umstellungszeitpunkt zu erledigen.

Das scheitert schon an der Definition von „ausreichend“.

Was ist eigentlich mit dem Fall, dass in der Zukunft entschieden werden könnte, vom jetzigen Zeitzählsystem wegzugehen und zum Beispiel auf Internetzeit umzustellen? Wenn du schon mit Zukunftssicherheit daherkommst, dann bitte auch alle möglichen Fälle und nicht nur einen einzelnen berücksichtigen ...

Tu ich. Ich würde immer und überall in UTC rechnen – gewissermaßen das UTF-8 unter den Zeitzonen.

Umrechnung in andere Zeitzonen ist lediglich eine Formatierung und erfolgt bei der Ausgabe. Bzw. gleich nach der Eingabe – bevor der Wert (in UTC) in einer DB landet.

Das ändert aber nichts daran, dass man mit dem 86400er-Code auch fehlerfrei zum Ziel kommen kann.

Aber eher schlecht als recht.

Und „schlecht“ sollte man möglichst vermeiden.

Siehe zweiter Teil.

LLAP 🖖

[dedlfix]

Tach!

Wäre hier sehr einfach durch eine Änderung der Stunde von Mittag auf eine andere Stunde mit ausreichendem Abstand zum Umstellungszeitpunkt zu erledigen.

Das scheitert schon an der Definition von „ausreichend“.

Wieso? War da wieder ein unsichtbarer Smiley? "Umstellungszeitpunkt" war jedenfalls nicht richtig in meiner Aussage, "Tagesgrenze" muss es sein. Und dabei offenbart sich mir gleich noch ein Denkfehler. Es ist völlig unerheblich, zu welchem Zeitpunkt am Tag die Umstellung stattfindet. Der gewählte Zeitpunkt für die Berechung muss nur genügend Platz für die Zeitdifferenz bieten. Bei einer Stunde ist es also nur wichtig, dass man eine Zeit zwischen 1 und 23 Uhr nimmt. Mit 12 Uhr ist man zukunftssicher, das bietet genug Platz für Zeitverschiebungen bis zu 11,9… Stunden. (Überstrich bekomme ich nicht hin.)

Tu ich. Ich würde immer und überall in UTC rechnen – gewissermaßen das UTF-8 unter den Zeitzonen.

Und da UTC keine Zeitverschiebung kennt, wäre das ganz klar kein Fall von Unfug, 86400 Sekunden als Tag anzunehmen. Wäre also auch eine Lösung, die gm*()-Funktionen zu nehmen.

dedlfix.

[Der Martin]

Hallo,

Tu ich. Ich würde immer und überall in UTC rechnen – gewissermaßen das UTF-8 unter den Zeitzonen.

Und da UTC keine Zeitverschiebung kennt, wäre das ganz klar kein Fall von Unfug, 86400 Sekunden als Tag anzunehmen.

Zeitverschiebung im Sinne von Zeitzonen gibt es da nicht - aber hin und wieder Schaltsekunden. Über einen Zeitraum von vielen Jahren kann sich also ein Fehler von ein paar Sekunden aufsummieren. Wird wohl für die meisten Anwendungen nicht relevant sein, aber Gunnar liebt Korinthen. ;-)

So long,
 Martin

[Gunnar Bittersmann]

@@dedlfix

Und da UTC keine Zeitverschiebung kennt, wäre das ganz klar kein Fall von Unfug, 86400 Sekunden als Tag anzunehmen.

Nur dass die auf Computern verwendete Zeit nicht UTC ist.

Und dass Der Martin schneller war.

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Nur dass die auf Computern verwendete Zeit nicht UTC ist.

Aber Gunnar, du hast doch geschrieben: „Ich würde immer und überall in UTC rechnen“!

Ja hab ich. Ich hätte es in Anführungszeichen setzen müssen: Ich würde immer und überall in „UTC“ rechnen.

LLAP 🖖

[dedlfix]

Tach!

Und da UTC keine Zeitverschiebung kennt, wäre das ganz klar kein Fall von Unfug, 86400 Sekunden als Tag anzunehmen.

Nur dass die auf Computern verwendete Zeit nicht UTC ist.

Wieso nicht? Der Unix-Timestamp basiert auf UTC.

Im vorliegenden Anwendungsfall ging es doch nur um das Datum. Da spielt der Zeit-Anteil keine Rolle. Es wurde lediglich eine Dummy-Zeit für die Berechnungsroutinen benötigt, die ohne Zeit nicht auskommen. Eine Umrechung von und zur Zeitzone des Computers, auf dem das Script läuft, ist im Prinzip nicht notwendig. Die kommt nur im Fehlerfall ins Spiel, wenn jemand aus dem Unix-Timestamp das Datum mit einer Nicht-UTC-Funktion umformen möchte, oder nicht UTC als zu verwendende Zeitzone angegeben hat. Also vorausgesetzt, man nimmt ansonsten die UTC-Funktionen oder Zeitzone.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Nur dass die auf Computern verwendete Zeit nicht UTC ist.

Wieso nicht? Der Unix-Timestamp basiert auf UTC.

Weil auch der UNIX-Timestamp nicht die seit 1970-01-01T00:00Z vergangenen Sekunden zählt.

Oder anders gesagt: Weil die Unix-Timestamp-Sekunden bei der Zählung nicht alle gleichlang sind.

LLAP 🖖

[Matthias Apsel]

Hallo dedlfix,

Zeitverschiebungen bis zu 11,9… Stunden. (Überstrich bekomme ich nicht hin.)

11,9 So ginge es, allerdings gibt es keine Neuner-Periode, weil es für ein und dieselbe Stelle auf der Zahlengeraden nicht mehrere verschiedene Dezimalbruchdarstellungen geben darf. 😛

11,9 = 12,0 = 12

Bis demnächst
Matthias

[Tagwächter]

Nein, es hat mich auch nicht interessiert. Aber ich würde dann eher nachfragen, was gemeint ist.

Ich gehe davon aus, dass PL manchmal nur deshalb ein "-1" bekommt, weil er es ist. Ansonsten werden falsche (hier nur eine klar richtige, gefolgt von einer unverständlichen) Aussagen ja auch toleriert.

[Der Martin]

Hallo,

Nein, es hat mich auch nicht interessiert. Aber ich würde dann eher nachfragen, was gemeint ist.

Ich gehe davon aus, dass PL manchmal nur deshalb ein "-1" bekommt, weil er es ist.

das glaube ich eher nicht; ich bin relativ sicher, dass es schon am Inhalt liegt. Allerdings fällt Rolf oft mit Aussagen auf, die entweder tatsächlich falsch oder zumindest grenzwertig sind, oder überhaupt nicht zur Frage passen, Hauptsache die Antwort enthält zwei, drei Zeilen Perl. Aufgrund dieser Häufung ist die Toleranzschwelle für ihn bei manchen Forumsnutzern vielleicht niedriger als für andere Schreiber.

Ansonsten werden falsche (hier nur eine klar richtige, gefolgt von einer unverständlichen) Aussagen ja auch toleriert.

Selbstverständlich toleriert (und meistens korrigiert), aber da gibt es auch noch so eine Art Nicht-schon-wieder-Effekt.

So long,
 Martin

[Tagwächter]

das glaube ich eher nicht; [...] aber da gibt es auch noch so eine Art Nicht-schon-wieder-Effekt.

Im Großen und Ganzen stimmst Du da meiner Aussage "Ich gehe davon aus, dass PL manchmal nur deshalb ein "-1" bekommt, weil er es ist." mit umfassender Begründung zu :-)

[Der Martin]

Hi,

das glaube ich eher nicht; [...] aber da gibt es auch noch so eine Art Nicht-schon-wieder-Effekt.

Im Großen und Ganzen stimmst Du da meiner Aussage "Ich gehe davon aus, dass PL manchmal nur deshalb ein "-1" bekommt, weil er es ist." mit umfassender Begründung zu :-)

nein, das habe ich nicht geschrieben und auch nicht gemeint. Und ich mag es nicht, wenn man Aussagen bewusst uminterpretiert, egal ob es meine Aussage ist oder die von jemand anderem.

Ich sagte genau das Gegenteil: Dass vielleicht die Toleranzschwelle etwas niedriger liegt, dass es aber gerade nicht nur deshalb passiert, weil er es ist.

Ciao,
 Martin

[Tagwächter]

Hi,

das glaube ich eher nicht; [...] aber da gibt es auch noch so eine Art Nicht-schon-wieder-Effekt.

Im Großen und Ganzen stimmst Du da meiner Aussage "Ich gehe davon aus, dass PL manchmal nur deshalb ein "-1" bekommt, weil er es ist." mit umfassender Begründung zu :-)

nein, das habe ich nicht geschrieben und auch nicht gemeint. Und ich mag es nicht, wenn man Aussagen bewusst uminterpretiert, egal ob es meine Aussage ist oder die von jemand anderem.

Ich sagte genau das Gegenteil: Dass vielleicht die Toleranzschwelle etwas niedriger liegt, dass es aber gerade nicht nur deshalb passiert, weil er es ist.

Ok. Dann beuge ich mich Deinen richtigen Ausführungen, streiche das "nur deshalb" und ändere also meine Behauptung in:

"Ich gehe davon aus, dass PL manchmal das "-1" bekommt, weil er es ist."

ab. Ich gehe davon aus, dass damit auch der Konsens erreicht ist.

[Gunnar Bittersmann]

@@Tagwächter

Ich gehe davon aus, dass PL manchmal nur deshalb ein "-1" bekommt, weil er es ist.

Ich gehe davon aus, dass PL manchmal nur deshalb kein "-1" bekommt, weil er es ist. ;-)

LLAP 🖖

[Tagwächter]

Ich gehe davon aus, dass PL manchmal nur deshalb ein "-1" bekommt, weil er es ist.

Ich gehe davon aus, dass PL manchmal nur deshalb kein "-1" bekommt, weil er es ist. ;-)

Tja. Demnach kommt es auch darauf an, wer seine mal mehr und mal weniger löblichen Beiträge liest.

[Der Buchhalter]

Nein, das liegt an dem Unfug, Tagesberechnungen über Sekunden durchzuführen. Aus diesem Grund gibt es ja auch nur eine Datumsgrenze auf dieser Welt und nicht 86400 was auf dem Äquator rund alle zwei Kilometer sein müsste.

MfG

Interessante Ansichten. Aber von welchem Planeten reden wir, wo die Datumsgrenze durch programmiertechnische Anforderungen begründet wird? Und müssen die Bewohner dort sehr weit Reisen um mal ein anderes Datum zu erleben, wenn es nur eine Datumsgrenze gibt? Immerhin umfasst der Äquator über 170.000 km? ;-)

PS: Die Negativ-Bewertung war schon vor mir da, aber ich kann sie gut nachvollziehen. Da fehlt mindestens ein Kaffee beim Autoren, oder die psychoaktiven Substanzen in meinem Kaffee.

[Tagwächter]

Und müssen die Bewohner dort sehr weit Reisen um mal ein anderes Datum zu erleben, wenn es nur eine Datumsgrenze gibt?

Tja.

Es ist ja erwiesen, dass Tage nicht unterschiedlich lang, sondern unterschiedlich breit sind. Und je breiter der Tag, so kürzer die Reise. Das ist einfach.

[pl]

Berechne Datum für die Zeitumstellung einfach so: Du brauchst den numerischen Wochentag für den 31.10 (letzter Tag im Monat). Das ist in diesem Jahr ein Montag und der hat die Nummer 1.

Wir rechnen: 31 - 1 und erhalten 30. Der 30.10.2016 ist also der letzte Sonntag an dem die Zeitumstellung erfolgt.

Anderes Beispiel: 2015 war der 31.10. an einem Sonnabend, der hat die Nummer 6. Also rechneten wir 31 - 6 und erhielten so den 25.10.2015 als denjenigen Sonntag an dem die Zeitumstellung erfolgte.

[Tagwächter]

Weil ich befürchte, dass die Diskussion abgleitet und künftige Leser die Nadel im Heuhaufen suchen müssen, hier die zielführenden Antworten:

• dedlix
• ich selbst