nicht angemeldet
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
Der Martin
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
MudGuard
Der Martin
Hi,
Eigentlich kein Problem, aber man kann ja eins draus machen: ;-)
function foo(date, timezone) {
if (timezone)
var date = new Date(Date.parse(date) + timezone * 3600000);
with (date)
return( /* some code */ );
}
Wenn ein (optionaler) Parameter timezone übergeben wird und dessen Wert von 0 verschieden ist, soll das lokale date-Objekt in der with-Anweisung verwendet werden, sonst das als Argument übergebene.
Funzen tut das[tm], aber ist das sauber?
Live long and prosper,
Gunnar
Hi,
function foo(date, timezone) {
[...]
var date = [...]
_das_ ist schon mal keine gute Idee :-)
Wenn ein (optionaler) Parameter timezone übergeben wird und dessen Wert von 0 verschieden ist, soll das lokale date-Objekt in der with-Anweisung verwendet werden, sonst das als Argument übergebene.
Funzen tut das[tm], aber ist das sauber?
Frage den Wert lieber mit typeof() ab. Das verhindert ggf. auch eine Warning.
Cheatah
function foo(date, timezone) {
[...]
var date = [...]_das_ ist schon mal keine gute Idee :-)
Cheatah,
Warum nicht? Was spricht dagegen?
Frage den Wert lieber mit typeof() ab.
Sollte doch in beiden Fällen derselbe sein.
Das verhindert ggf. auch eine Warning.
Hab noch keine bekommen. (Auch keine Warnung. ;-) SCNR.)
Live long and prosper,
Gunnar
Hi,
function foo(date, timezone) {
var date = [...]
_das_ ist schon mal keine gute Idee :-)
Warum nicht? Was spricht dagegen?
eine Variable zu deklarieren, die schon übergeben wurde? Das fragst Du nicht wirklich, oder? ;-)
Frage den Wert lieber mit typeof() ab.
Sollte doch in beiden Fällen derselbe sein.
Bis auf die Warning. Und den Typecast.
Das verhindert ggf. auch eine Warning.
Hab noch keine bekommen.
Bei hinreichend strenger Konfiguration - was für die Entwicklung empfehlenswert ist - sollte Mozillas JavaScript-Konsole welche anzeigen.
(Auch keine Warnung. ;-) SCNR.)
Die gibt's eh nur in deutschsprachigen Browsern ;-)
Cheatah
Warum nicht? Was spricht dagegen?
eine Variable zu deklarieren, die schon übergeben wurde? Das fragst Du nicht wirklich, oder? ;-)
Cheatah,
Ich tu sonst immer so klug hier; lass mich doch auch mal dummtun.
Nachdem ich das übergebene date auf der rechten Seite von
var date = new Date(Date.parse(date) + timezone * 3600000);
benutzt habe, brauche ich das übergebene nicht mehr. Also warum nicht lokal eine Variable gleichen Namens anlegen?
Frage den Wert lieber mit typeof() ab.
Sollte doch in beiden Fällen derselbe sein.
Bis auf die Warning.
In der JavaScript-Konsole des Firefox’ gibt’s keine Warnung. Hab grad keinen Mozilla da. Was sagt der?
Und den Typecast.
??
Natürlich könnte ich auch in beiden Fällen (timezone != 0 bzw. undefined oder 0) ein neues lokales Objekt erzeugen und das anders benennen. Das will ich aber gerade umgehen, da das ja im Fall undefined oder 0 nicht notwendig ist und die Ausführung unnötig verlangsamen würde. Die Funktion soll möglichst aber schnell sein.
Zum Ansehen: http://gunnarbittersmann.de/Scripts/date.js (Wie war das mit „Den Code zu lesen und ihn zu verstehen sind fast deckungsgleich“? [Cheatah] ;-))
Anwendung in http://gunnarbittersmann.de/2005/weltzeituhr.html
Live long and prosper,
Gunnar
你好 Gunnar,
Nachdem ich das übergebene date auf der rechten Seite von
var date = new Date(Date.parse(date) + timezone * 3600000);
benutzt habe, brauche ich das übergebene nicht mehr. Also warum nicht
lokal eine Variable gleichen Namens anlegen?
Das ist ein Trugschluss, das passiert nicht. Das Schlüsselwort var wird in
diesem Fall schlicht ignoriert.
Frage den Wert lieber mit typeof() ab.
Sollte doch in beiden Fällen derselbe sein.
Bis auf die Warning.In der JavaScript-Konsole des Firefox’ gibt’s keine Warnung. Hab grad
keinen Mozilla da. Was sagt der?
Vorab: Warnings stellst du ein, wenn du in about:config
javascript.options.strict auf true setzt. Dann: es gibt (in diesem Fall)
keine Warning.
再见,
克里斯蒂安
Hallo Christian.
Dann: es gibt (in diesem Fall)
keine Warning.
Hm?
---
Warnung: variable date hides argument
Quelldatei: http://gunnarbittersmann.de/Scripts/date.js
Zeile: 8, Spalte: 6
Quelltext:
var date = new Date(Date.parse(date) + tz * 3600000);
Warnung: deprecated with statement usage
Quelldatei: http://gunnarbittersmann.de/Scripts/date.js
Zeile: 10, Spalte: 120
Quelltext:
Math.floor(a = Math.abs(tz))) < 10 ? "0" : "") + b + ":" + ((b = Math.round((a - b) * 60)) < 10 ? "0" : "") + b : "Z")));
Warnung: assignment to undeclared variable tz
Quelldatei: http://gunnarbittersmann.de/2005/weltzeituhr.html
Zeile: 15
Warnung: assignment to undeclared variable dd
Quelldatei: http://gunnarbittersmann.de/2005/weltzeituhr.html
Zeile: 16
Warnung: assignment to undeclared variable utc
Quelldatei: http://gunnarbittersmann.de/2005/weltzeituhr.html
Zeile: 17
Warnung: assignment to undeclared variable local
Quelldatei: http://gunnarbittersmann.de/2005/weltzeituhr.html
Zeile: 17
Warnung: assignment to undeclared variable user
Quelldatei: http://gunnarbittersmann.de/2005/weltzeituhr.html
Zeile: 17
Warnung: assignment to undeclared variable dateTime
Quelldatei: http://gunnarbittersmann.de/2005/weltzeituhr.html
Zeile: 21
---
Einen schönen Sonntag noch.
Gruß, Ashura
你好 Ashura,
Hallo Christian.
Dann: es gibt (in diesem Fall)
keine Warning.Hm?
[…]
Es ging doch um den Fall, ob if(timezone) eine Warning verursacht wenn
timezone nicht definiert ist. Deine Warnings haben nichts mit diesem Fall
zu tun.
再见,
克里斯蒂安
Hallo Christian.
Es ging doch um den Fall, ob if(timezone) eine Warning verursacht wenn
timezone nicht definiert ist.
Achso.
Einen schönen Sonntag noch.
Gruß, Ashura
Warnung: variable date hides argument
var date = new Date(Date.parse(date) + tz * 3600000);
OK, kommt ohne var nicht mehr.
Warnung: deprecated with statement usage
Heißt, dass man with überhaupt nicht mehr verwenden sollte?
Also foo.bar(); foo.baz();
statt with(foo) {bar(); baz();}?
Wäre die Ausführung mit with nicht schneller? (Noch nicht getestet.)
Warnung: assignment to undeclared variable tz
Warnung: assignment to undeclared variable dd
Warnung: assignment to undeclared variable utc
Warnung: assignment to undeclared variable local
Warnung: assignment to undeclared variable user
Warnung: assignment to undeclared variable dateTime
Ups, wo kommen die her? Sollte ich in Funktionen keine globalen Variablen (erstmals) setzen?
Live long and prosper,
Gunnar
你好 Gunnar,
Warnung: assignment to undeclared variable tz
Warnung: assignment to undeclared variable dd
Warnung: assignment to undeclared variable utc
Warnung: assignment to undeclared variable local
Warnung: assignment to undeclared variable user
Warnung: assignment to undeclared variable dateTimeUps, wo kommen die her? Sollte ich in Funktionen keine globalen Variablen
(erstmals) setzen?
Eine Warnung ist eine Warnung, nicht mehr und nicht weniger. Das bedeutet,
der Interpreter vermutet, dass da ein Fehler sein _könnte_. Es muss keiner
sein. Wenn du weisst, dass das so richtig ist, dann kannst du die Warnung
getrost ignorieren.
再见,
克里斯蒂安
Eine Warnung ist eine Warnung, nicht mehr und nicht weniger.
Da ignoriere ich doch auch glatt die Warnungen, die mir der Validator für http://gunnarbittersmann.de/2005/weltzeituhr.html wegen der "&&" im Quelltext (XHTML) ausspuckt.
Oder sollte ich das dann doch lieber als HTML 4.01 schreiben, wenn ich das Script nicht auslagern will?
Live long and prosper,
Gunnar
你好 Gunnar,
Eine Warnung ist eine Warnung, nicht mehr und nicht weniger.
Da ignoriere ich doch auch glatt die Warnungen, die mir der Validator für
http://gunnarbittersmann.de/2005/weltzeituhr.html wegen der "&&"
im Quelltext (XHTML) ausspuckt.Oder sollte ich das dann doch lieber als HTML 4.01 schreiben, wenn ich
das Script nicht auslagern will?
Was spricht gegen
//<![CDATA[
//]]>
再见,
克里斯蒂安
Hi Christian,
Was spricht gegen
//<![CDATA[
//]]>
Ähm, weiß nicht … nichts? ;-)
Live long and prosper,
Gunnar
PS. Was spricht dagegen, [codе] ohne Sprachangabe für Posten im Forum ohne Warnung (diese ignoriere ich auch gerne) zuzulassen?
Gibt es für präformatierten Text sowas wie [prе] oder muss man dafür zum Missbauch von [codе] greifen?
Hallo Gunnar,
Gibt es für präformatierten Text sowas wie [prе] oder muss man dafür zum Missbauch von [codе] greifen?
wozu denn noch?
Hier im Forum werden doch mittlerweile alle Leerzeichen und Zeilenumbrüche exakt wie eingegeben auch übernommen - was willst du noch mehr?
Ich erinnere mich an Zeiten (ist noch gar nicht lange her), als Leerzeichen am Zeilenanfang im Posting ignoriert wurden; das ist ja inzwischen zum Glück korrigiert worden.
Also wozu noch der Ruf nach <pre>?
So long,
Martin
Also wozu noch der Ruf nach <pre>?
Martin,
Um Tabellen darstellen (wie z.B. in http://forum.de.selfhtml.org/archiv/2005/10/t117410/#m752604)
Es soll Nutzer geben, die andere Schrift als eine diktengleiche eingestellt haben. ;-)
Live long and prosper,
Gunnar
Hallo,
Um Tabellen darstellen (wie z.B. in http://forum.de.selfhtml.org/archiv/2005/10/t117410/#m752604)
Es soll Nutzer geben, die andere Schrift als eine diktengleiche eingestellt haben. ;-)
Echt?
Was für'n Unsinn.
Selber schuld...
Gute Nacht auch,
Martin
Es soll Nutzer geben, die andere Schrift als eine diktengleiche eingestellt haben. ;-)
Echt?
Ja.
Was für'n Unsinn.
Nein.
Selber schuld...
Liest sich besser. Außer eben bei Tabellen. Und bei ASCII-Art. Und bei
H H
C = C
CH3 OH
Warum ich da nicht gleich drauf gekommen bin, http://forum.de.selfhtml.org/archiv/2005/10/t117542/#m753241 als Beispiel anzuführen … ;-)
Live long and prosper,
Gunnar
你好 Gunnar,
PS. Was spricht dagegen, [codе] ohne Sprachangabe für Posten im Forum
ohne Warnung (diese ignoriere ich auch gerne) zuzulassen?
Die Warnung ist genau das gleiche wie die Warnung eines JS-Interpreters: es
_könnte_ ein Fehler vorliegen. Muss aber nicht. Es ist kein Fehler, code
ohne lang zu posten, aber es könnte ein potentieller Fehler sein.
Gibt es für präformatierten Text sowas wie [prе] […]
Nein.
再见,
克里斯蒂安
Gibt es für präformatierten Text sowas wie [prе] […]
Nein.
Christian,
Sollte es aber IMHO ruhig geben.
Es mag ja Nutzer geben, die sich auch code-Bereiche in Proportionalschrift anzeigen lassen wollen.
Da wären Tags [pre] [/pre], die in <pre> </pre> umgewandelt werden, doch hilfreich.
Wer sich pre dann anders formatiert, der ist wirklich „selber schuld“.
Live long and prosper,
Gunnar
你好 Gunnar,
Wer sich pre dann anders formatiert, der ist wirklich „selber schuld“.
Wer sich code anders formatiert ist genau so selber schuld. Ich halte pre
für völlig überflüssig.
再见,
克里斯蒂安
Hi Christian,
Wer sich code anders formatiert ist genau so selber schuld. Ich halte pre
für völlig überflüssig.
Wo bleibt denn da das „semantische Markup“? ;-)
Live long and prosper,
Gunnar
你好 Gunnar,
Wer sich code anders formatiert ist genau so selber schuld. Ich halte
pre für völlig überflüssig.Wo bleibt denn da das „semantische Markup“? ;-)
Hehe, der Output der Postings ist eh nicht semantisch und wird es auch nie
werden (könne) ;)
再见,
克里斯蒂安
Hallo Gunnar.
Warnung: deprecated with statement usage
Heißt, dass man
withüberhaupt nicht mehr verwenden sollte?
Ich habe diese Meldung noch ein paar Mal finden können, jedoch keine Begründung.
Möglicherweise hängt es einfach nur mit sauberem Stil zusammen.
Also
foo.bar(); foo.baz();
stattwith(foo) {bar(); baz();}?Wäre die Ausführung mit
withnicht schneller? (Noch nicht getestet.)
Je nach Umfang der abzuarbeitenden Befehle kann erstere Schreibweise sicher schneller sein, aber auch ich habe es nicht getestet.
Warnung: assignment to undeclared variable tz
Warnung: assignment to undeclared variable dd
Warnung: assignment to undeclared variable utc
Warnung: assignment to undeclared variable local
Warnung: assignment to undeclared variable user
Warnung: assignment to undeclared variable dateTimeUps, wo kommen die her? Sollte ich in Funktionen keine globalen Variablen (erstmals) setzen?
Laut Warnungen ja.
Einen schönen Sonntag noch.
Gruß, Ashura
Hallo Gunnar.
In der JavaScript-Konsole des Firefox’ gibt’s keine Warnung.
Dann wechsele einmal zum Strict-Mode:
about:config
-> javascript.options.strict = true
Einen schönen Sonntag noch.
Gruß, Ashura
Hallo,
Nachdem ich das übergebene date auf der rechten Seite von
var date = new Date(Date.parse(date) + timezone * 3600000);
benutzt habe, brauche ich das übergebene nicht mehr. Also warum nicht lokal eine Variable gleichen Namens anlegen?
Warum nicht einfach den Wert des übergebenen Parameters ändern? Lass das "var" doch einfach weg. Es gibt die Variable "date" bereits im Gültigkeitsbeich der Funktion.
viele Grüße
Axel
Axel,
Hallo,
Nachdem ich das übergebene date auf der rechten Seite von
var date = new Date(Date.parse(date) + timezone * 3600000);
benutzt habe, brauche ich das übergebene nicht mehr. Also warum nicht lokal eine Variable gleichen Namens anlegen?Warum nicht einfach den Wert des übergebenen Parameters ändern? Lass das "var" doch einfach weg.
Ich hatte gedacht, damit eine außerhalb der Funktion vorhandene Variable date zu überschreiben …
Es gibt die Variable "date" bereits im Gültigkeitsbeich der Funktion.
… aber nein, date ist lokal.*
Das war es, was Chetah mir sagen wollte?
Live long and prosper,
Gunnar
* Von Sprachspielereien abgesehen:
• date ist temporal
• Ist doch klar, dass man sich an einem Ort trifft; wären zwei an verschiedenen Orten, hätten sie ja kein Date.
• …
Hallo,
Ich hatte gedacht, damit eine außerhalb der Funktion vorhandene Variable date zu überschreiben …
Nein, dazu müsstest Du window.date ansprechen.
… aber nein, date ist lokal.*
Nein, es liegt im Gültigkeitsbereich der Funktion. Ganz JavaScript ist lokal, oder? ;-)
• Ist doch klar, dass man sich an einem Ort trifft; wären zwei an verschiedenen Orten, hätten sie ja kein Date.
Nein, aber eventuell zwei?
F: Wie viele Männer sprechen nach dem Geschlechtsverkehr mit ihrer Frau?
A: Das hängt hauptsächlich davon ab, ob ein Telefon in der Nähe ist.
viele Grüße
Axel
你好 Cheatah,
function foo(date, timezone) {
[...]
var date = [...]_das_ ist schon mal keine gute Idee :-)
In JS ist das möglich und hat auch keine unangenehmen Nebeneffekte. Es gibt
keinen tieferen Scope als den Funktions-Scope. Es ist allerhöchstens
stilistisch gesehen nicht die feine englische Art.
再见,
克里斯蒂安
Hi,
In JS ist das möglich und hat auch keine unangenehmen Nebeneffekte.
bis auf die Warnings. Man kann natürlich immer sagen, dass sie ja nur warnen sollen - richtig, nämlich vor eventuell schwerwiegenden Fehlern. Wer eine Variable deklariert, die schon deklariert ist, macht in aller Regel[1] etwas anderes als das, was er eigentlich will.
Cheatah
[1] Gegenbeispiel: Schleifenvariable.
你好 Cheatah,
Hi,
In JS ist das möglich und hat auch keine unangenehmen Nebeneffekte.
bis auf die Warnings.
Ich sagte ja: es ist höchstens stilistisch ein Fehler. Es hat keine
Nebeneffekte („var variable“ ändert den Wert nicht). Das einzige, was auf
ein logisches Problem hindeutet, ist das Schlüsselwort „var“.
Wer eine Variable deklariert, die schon deklariert ist, macht in aller
Regel[1] etwas anderes als das, was er eigentlich will.
[…]
[1] Gegenbeispiel: Schleifenvariable.
Auch hier wäre das strengenommen der gleiche potentielle Fehler. Jemand,
der eine bestehende Schleifen-Variable neu deklariert, hat keinen Überblick
darüber, welche Variablen er in seinem Code-Stück verwendet.
再见,
克里斯蒂安
Hi,
Ich sagte ja: es ist höchstens stilistisch ein Fehler.
richtig :-)
Es hat keine Nebeneffekte („var variable“ ändert den Wert nicht).
Interessant, dass Du erst sagst, es gäbe keine Nebeneffekte, und dann gleich einen nennst. Bei der Deklaration einer Variable kann man erwarten, dass sie mit einem definierten Initialwert gefüllt wird.
Jemand,
der eine bestehende Schleifen-Variable neu deklariert, hat keinen Überblick
darüber, welche Variablen er in seinem Code-Stück verwendet.
Jein. Ein
for (var i=0; i<irgendwas; i++)
geht relativ routiniert von der Hand und ist i.d.R. auch nicht besonders bemerkenswert. Wenn nun in der selben Code-Ebene eine weitere Schleife folgt, erachte ich eine Redeclaration als ziemlich natürlich. Ich stehe immer wieder vor dem Zwiespalt, die Warning zu ignorieren oder den eher unintuitiven Code ohne Deklaration zu wählen.
Cheatah
你好 Cheatah,
Es hat keine Nebeneffekte („var variable“ ändert den Wert nicht).
Interessant, dass Du erst sagst, es gäbe keine Nebeneffekte, und dann
gleich einen nennst.
Ein Nebeneffekt wäre es, wenn die Variable mit ihrem Initialwert befüllt
würde: es wird ein Status geändert. Ich mache ja schliesslich eine
Deklaration, keine Initialisierung.
Bei der Deklaration einer Variable kann man erwarten, dass sie mit einem
definierten Initialwert gefüllt wird.
Nein, bei einer Deklaration hat der Inhalt gefälligst nicht geändert zu
werden. Das muss bei einer Initialisierung passieren.
Jein. Ein
for (var i=0; i<irgendwas; i++)
geht relativ routiniert von der Hand und ist i.d.R. auch nicht besonders
bemerkenswert. Wenn nun in der selben Code-Ebene eine weitere Schleife
folgt, erachte ich eine Redeclaration als ziemlich natürlich.
Ja, da hast du recht.
Ich stehe immer wieder vor dem Zwiespalt, die Warning zu ignorieren oder
den eher unintuitiven Code ohne Deklaration zu wählen.
Ich ignoriere die Warnings in diesem Fall grundsätzlich, da bei einer
späteren Änderung die erste Schleife eventuell entfallen könnte. Und damit
hätte man dann einen hausgemachten Bug.
再见,
克里斯蒂安
Hi,
Bei der Deklaration einer Variable kann man erwarten, dass sie mit einem definierten Initialwert gefüllt wird.
nein, das erwarte ich erst bei der Initialisierung oder Definition (Deklaration und Intitialisierung in einer Anweisung).
Wenn nun in der selben Code-Ebene eine weitere Schleife folgt, erachte ich eine Redeclaration als ziemlich natürlich. Ich stehe immer wieder vor dem Zwiespalt, die Warning zu ignorieren oder den eher unintuitiven Code ohne Deklaration zu wählen.
Da bin ich als gewohnheitsmäßiger C-Programmierer ganz anders geprägt. Am Anfang eines neuen Scopes (i.d.R. Funktionskopf) wird eine Variable deklariert, und dann kann ich sie innerhalb des Scopes beliebig oft wiederverwenden. Dabei muss ich selbst darauf achten, ob ich die bisher zugewiesenen Werte überschreiben will/darf oder nicht.
Mich stört schon die Schlampigkeit, die mit C++ eingeführt wurde, dass man neue Variablen an jeder Stelle im Programmcode deklarieren kann.
Schönen Abend noch,
Martin
Hi,
Das liebe ich an diesem Forum: Man stellt eine Frage und bekommt auch noch gleich zehn andere beantwortet. Schade eigentlich, dass viele N00bs und Ewig-N00bs das nicht als Vorteil erkennen.
Dank euch ist das var jetzt weg (Nun sollte es sauber sein?) und meine JavaScript-Konsole zeigt auch Warn_u_ngen an. :-) Danke.
Durch erzwungenes Mitdenken ist mir noch aufgefallen, dass ich
date = new Date(Date.parse(date) + tz * 3600000);
ja gar nicht brauche. Es geht schnell und einfach
date += tz * 3600000;
Live long and prosper,
Gunnar
PS. Das Debuggen bei verschachtelten bedingten Zuweisungen (foo ? (bar ? baz : quz) : quuz) und Zuweisungen in Operationen (foo = (bar = baz + quz) + quuz) ist eine Katastrophe!
Vielleicht hätte ich den Link zum vollständigen Script nicht posten sollen, sondern ein Rätsel zum Wochenende draus machen?
Durch erzwungenes Mitdenken ist mir noch aufgefallen, dass ich
date = new Date(Date.parse(date) + tz * 3600000);
ja gar nicht brauche. Es geht schnell und einfach
date += tz * 3600000;
Was immer mich in diesen Wahnsinn trieb …
Gibt es eine bessere Möglichkeit, tz Stunden zum Zeitpunkt date zu addieren (wobei tz auch negativ sein kann) als
date = new Date(Date.parse(date) + tz * 3600000);?
Live long and prosper,
Gunnar
PS. Da ich sowieso die if (tz)-Abfrage in der Funktion toISO8601String() hatte, hab ich den bedingten Ausdruck noch in zwei kürzere geteilt …
Hi,
No ’ne Frage zu Uhrzeitanzeigescripts.
Hypothetische Annahme: Es gibt sinnvolle Anwendungen. ;-)
Disclaimer: Die Weltzeituhr-Seite war eigentlich nur zum Testen der
toISO8601String()-Funktion gedacht. Ist dann etwas mehr Spielerei draus geworden.
function foo() {
refreshDisplay();
window.setTimeout("foo()", 1000);
}
braucht ja zum Ausführen von refreshDisplay() etwas Zeit, sagen wir 42 ms. Der Aufruf von foo() – die Aktualisierung der Zeitanzeige – ist also nicht jede Sekunde, sondern alle 1042 ms.
Ruft man foo() erstmals um 00:00:00.000 auf, erfolgen die weiteren Aufrufe
00:00:01.042
00:00:02.084
00:00:03.126
[gähn]
00:00:22.924
00:00:23.966
00:00:25.008
Die Uhrzeitanzeige springt also von 00:00:23 auf 00:00:25.
Setzt man den Timeout kürzer, sagen wir 950 ms (bei 42 ms für foo()):
00:00:00.942
00:00:01.884
00:00:02.826
[gähn]
00:00:16.014
00:00:16.956
00:00:17.898
Die Anzeige verweilt fast zwei Sekunden lang auf 00:00:16.
Die Anpassung der Länge des Timeouts (window.setTimeout("foo()", 968);) ist ja nicht wirklich eine Lösung, da die 42 ms für ein bestimmtes System gelten; auf anderen sind es mehr oder weniger.
Das Auffrischen der Anzeige alle Zehntelsekunde ist wohl Verschwendung von Rechenleistung. Interupt-gesteuerte Funktionsaufrufe gibt’s wohl in JavaScript nicht.
Muss man also mit Unregelmäßigkeiten bei der Anzeige (manche Sekunden doppelt oder übersprungen) leben?
Live long and prosper,
Gunnar
Ehe ich zum Nachsitzen verdonnert werde:
Setzt man den Timeout kürzer, sagen wir 950 ms (bei 42 ms für
foo()):
00:00:00.942
00:00:01.884
00:00:02.826
Ich wollte es erst für 950 ms rechnen, hab’s dann aber für 900 ms getan und vergessen, das oben abzuändern.
Die Anpassung der Länge des Timeouts (
window.setTimeout("foo()", 968);) ist ja nicht wirklich eine Lösung,
Zumal 1000 - 42 = 958.
Live long and prosper,
Gunnar
Hi,
function foo() {
refreshDisplay();
window.setTimeout("foo()", 1000);
}
> braucht ja zum Ausführen von `refreshDisplay()`{:.language-javascript} etwas Zeit, sagen wir 42 ms. Der Aufruf von `foo()`{:.language-javascript} – die Aktualisierung der Zeitanzeige – ist also nicht jede Sekunde, sondern alle 1042 ms.
setInterval?
cu,
Andreas
--
[Warum nennt sich Andreas hier MudGuard?](http://www.Mud-Guard.de/)
[Schreinerei Waechter](http://www.schreinerei-waechter.de/)
Fachfragen per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.
setInterval?
Andreas,
Die Beschreibung in SELFHTML liest sich erstmal gut.
Die Implementierung hält jedoch nicht was die Beschreibung verspricht: Die Anzeige stockt noch mehr als bei setTimeout (Firefox, IE).
Live long and prosper,
Gunnar
Moin Gunnar,
Hypothetische Annahme: Es gibt sinnvolle Anwendungen. ;-)
okay, mal angenommen. ;-)
function foo() {
refreshDisplay();
window.setTimeout("foo()", 1000);
}
>
> braucht ja zum Ausführen von `refreshDisplay()`{:.language-javascript} etwas Zeit, sagen wir 42 ms. Der Aufruf von `foo()`{:.language-javascript} – die Aktualisierung der Zeitanzeige – ist also nicht jede Sekunde, sondern alle 1042 ms.
In solchen Fällen tendiere ich dazu, den neuen Aufruf der Funktion schon zu "bestellen", bevor ich die eigentliche Arbeit erledige:
> ~~~javascript
function foo() {
> window.setTimeout("foo()", 1000);
> refreshDisplay();
> }
So geht der Zeitbedarf von refreshDisplay() nicht mehr in die Intervallzeit ein. In der wirklichen Welt muss man dann auf mögliche Rekursionen achten; u.U. hat es böse Folgen, wenn die Funktion "sich selbst überholt". Ob das im Zusammenhang mit setTimeout() in einer Browserumgebung auch problematisch ist, weiß ich nicht; ich vermute nein.
Das ändert aber nichts daran, dass ein Browser nun mal keine typische Echtzeitanwendung ist und somit schon vom OS kein garantiertes Zeitverhalten für sich beanspruchen kann. Browserinterne Scripts können sich also noch weniger darauf verlassen, dass Timerfunktionen pünktlich aufgerufen werden. Bei hoher Systemauslastung kann es schon mal sein, dass sich der Aufruf um ein paar Sekunden verspätet.
Daher erscheint es mir müßig, solche Zeitanzeige-Scripts nur der flüssigen Anzeige wegen auf eine Zehntelsekunde oder noch besser zu optimieren.
Schönen Tag noch,
Martin
hi,
abgesehen von Andreas' Hinweis auf setInterval -
Muss man also mit Unregelmäßigkeiten bei der Anzeige (manche Sekunden doppelt oder übersprungen) leben?
erwartest du wirklich Betrachter, die minutenlang mit solcher Faszination auf eine Uhrzeitanzeige starren werden, so dass ihnen dieses Phänomen überhaupt auffällt ...?
gruß,
wahsaga
Hallo Gunnar,
Rechne doch einfach aus, in wie vielen Millisekunden die Sekunde abläuft.
Die Zeit, die Du brauchst, um das auszurechnen, fällt sicher nicht ins Gewicht.
Die Lösung hat auch den Vorteil, dass die Anzeige wirklich beim Sekundenwechsel aktualisiert wird.
Grüße
Daniel
Rechne doch einfach aus, in wie vielen Millisekunden die Sekunde abläuft.
Hi Daniel,
Ich war erstmal recht skeptisch, aber mal sehen …
Die Zeit, die Du brauchst, um das auszurechnen, fällt sicher nicht ins Gewicht.
Hm, immerhin ein zusätzlicher Aufruf von new Date().
Du meintest das doch so in der Art?
function insertDateTime() {
dateTime = new Date();
utc.nodeValue = toISO8601String(dateTime, 0);
local.nodeValue = toISO8601String(dateTime);
user.nodeValue = toISO8601String(dateTime, tz);
execTime = new Date().getTime() - dateTime.getTime();
window.setTimeout("insertDateTime()", 1000 - execTime);
}
JavaScript mag vorgaukeln, in Millisekunden zu rechnen, nimmt’s aber doch nicht so genau: alert (execTime) ergibt entweder 0 oder 50.
Aber dennoch läuft die Zeitanzeige damit stabiler, es gibt zwar hin und wieder noch Hopser, aber es sind weniger.
Gar nicht so dumm. :-)
Live long and prosper,
Gunnar
Aber dennoch läuft die Zeitanzeige damit stabiler, es gibt zwar hin und wieder noch Hopser, aber es sind weniger.
… anzusehen auf http://gunnarbittersmann.de/2005/weltzeituhr-20051031.html
Live long and prosper,
Gunnar
Hallo Gunnar,
Sieht gut aus, bei mir hopst da auch nichts. Die Uhr läuft sehr schön Synchron mit meiner Rechneruhr.
Grüße
Daniel
Hallo,
wollte nur anmerken, falls es noch keinem aufgefallen ist, dass der
Aufruf von insertDateTime bei onclick und jetziger Implementation der
Funktion (ständiges setTimeout), nicht so ideal ist;)
bernd
wollte nur anmerken, falls es noch keinem aufgefallen ist, dass der
Aufruf von insertDateTime bei onclick und jetziger Implementation der
Funktion (ständiges setTimeout), nicht so ideal ist;)
bernd,
Du meinst, wenn um 00:00:04.2 das onclick-Ereignis eintritt, dass dann insertDateTime() zweimal pro Sekunde aufgerufen wird?
00:00:05.0
00:00:05.2
00:00:06.0
00:00:06.2
00:00:07.0
00:00:07.2
Ist das so?
Live long and prosper,
Gunnar
Du meinst, wenn um 00:00:04.2 das onclick-Ereignis eintritt, dass dann insertDateTime() zweimal pro Sekunde aufgerufen wird?
Ist das so?
Ja, das ist so. Und das ist schlecht.
Ich hatte anfangs auch nur onclick="[code lang=javascript]tz++"[/code] bzw. onclick="[code lang=javascript]tz--"[/code] da zu stehen. Dann erfolgt die Reaktion auf die Nutzeraktion im worst case aber erst eine Sekunde später; das ist inakzeptabel. (http://gunnarbittersmann.de/2005/weltzeituhr-20051030.html hab ich auf diesen Stand zurückversetzt.)
In http://gunnarbittersmann.de/2005/weltzeituhr-20051031.html lass ich jetzt beim Click auf die Buttons nur einmalig die Zeitanzeige in der gewählten Zeitzone ändern.
Vielen Dank für den Hinweis.
Live long and prosper,
Gunnar
Hallo,
ja wunderbar. Eine Frage noch, bringt es was, wenn man den
nächsten Aufruf so berechnet, dass er genau eine Sekunde
nach dem jetzigen erfolgt?
window.setTimeout("insertDateTime()", 1000 - (new Date().getTime()) + dateTime.getTime());
Wäre es nicht sinnvoller, den nächsten Aufruf so zu berechnen,
dass die Funktion beim nächsten Sekundenwechsel aufgerufen wird.
window.setTimeout("insertDateTime()", 1000 - (new Date()).getMiliseconds());
Ist nur so ein Gedanke gewesen, weil mir oben aufgefallen ist, dass
sich auch negative Werte ergeben könnnten (unwahrscheinlich aber möglich).
bernd
Wäre es nicht sinnvoller, den nächsten Aufruf so zu berechnen,
dass die Funktion beim nächsten Sekundenwechsel aufgerufen wird.
window.setTimeout("insertDateTime()", 1000 - (new Date()).getMiliseconds());
Ja, bernd,
Das war’s wohl auch, was [Daniel] meinte.
Aktuelle Version: http://gunnarbittersmann.de/2005/weltzeituhr-20051101.html
Live long and prosper,
Gunnar
PS. Unterscheidet sich window.setTimeout("insertDateTime()", 1000 - (new Date().getMiliseconds())); (schließende Klammer an anderer Stelle) in der Ausführung in irgendeiner Weise?
PS. Unterscheidet sich
window.setTimeout("insertDateTime()", 1000 - (new Date().getMiliseconds()));(schließende Klammer an anderer Stelle) in der Ausführung in irgendeiner Weise?
(Davon abgesehen, dass die Methode getMiliseconds() unbekannt ist, um MudGuard zuvorzukommen ;-))
Live long and prosper,
Gunnar
Hallo,
PS. Unterscheidet sich
window.setTimeout("insertDateTime()", 1000 - (new Date().getMiliseconds()));(schließende Klammer an anderer Stelle) in der Ausführung in irgendeiner Weise?
so wie du es geschrieben hast gibt es keinen gravierenden Unterschied.
Anders sieht es aus, wenn du dem Konstruktor keine Parameter übergibst und
auch die Klammern wegläßt, was ja legitim ist.
alert((new Date).getMilliseconds()); // OK
alert(new Date.getMilliseconds()); // Fehler
Beim ersten Beispiel ist es halt eindeutig, dass auf eine Methode der
neuen Instanz von Date zugegriffen werden soll. Beim zweiten gibt's einen
Fehler, da es keine statische Methode getMilliseconds gibt bzw. genauer
gesagt die Vorlage für den Konstruktor fehlt (siehe weiter unten).
Date.getMilliseconds = function()
{
return 42;
}
alert(Date.getMilliseconds()) // 42
alert(new Date.getMilliseconds()) // 42?
alert((new Date).getMilliseconds()); // Die aktuellen Millisekunden
Wenn man das mal laufen läßt wird man feststellen, dass im zweitem Beispiel
ein Objekt zurückgeliefert wird, nicht aber die Zahl 42. Warum?
Der new-Operator bewirkt ja folgendes:
1. Es wird eine Instanz von Object erzeugt
2. Es wird anschließend der Konstruktor für das Objekt aufgerufen. Der Konstruktor
ist ja eine Funktion die als Vorlage dient wobei auf das erzeugte Objekt über
den this-Zeiger zugegriffen werden kann.
3. Der Konstruktor initialisiert das Objekt mit den übergebenen Werten (Parameter).
Soll heißen, dass die Werte aus der Parameterliste über den this-Zeiger der neuen
Instanz zugewiesen werden können. Ist unwichtig steht aber so in der Doku;)
Im zweiten Beispiel wird also in Schritt 2 für den Konstruktor (Vorlage)
"Date.getMilliseconds" aufgelöst und die letzte Klammer stellt die Parameterliste
für selbigen dar.
// Konstruktor im zweiten Beispiel.
function()
{
return 42;
}
Ändern wir mal diesen "Konstruktor" und nutzen Parameter für
die Initialisierung.
Date.getMilliseconds = function(name)
{
this.name = name;
return 42; // Rückgabewerte im Konstruktor haben keine Bedeutung
}
alert(new Date.getMilliseconds("Gunnar").name); // "Gunnar"
So, ich hoffe das war so korrekt und verständlich. Bin mir sicher dass du das so auch
schon vermutet hast aber die Nachwelt soll ja auch was zum lesen haben.
bernd