nicht angemeldet
Der Martin
Gunnar Bittersmann
tk
MudGuard
Der Martin
Gunnar Bittersmann
Gunnar Bittersmann
Matti Mäkitalo
Guten Tag
Meine Frage etwas präziser:
Ist es möglich eine Funktion umzusetzen, die es ermöglicht Zeiten anhand der IP zusteuern?
Hier geht es speziell um einen Sendeplan.
Im Sendeplan wird 9 Uhr angezeigt, nun ist aber ein User aus der USA auf der Seite, der liest dann auch 9Uhr.
Das möchte ich eigentlich umgehen, so das der User den Sendungsbeginn sieht anhand seines IP-Standortes.
Dieses wäre als Beispiel dann 4Uhr.
Ist es möglich ein Script so anzupassen und wie sieht soetwas aus(muss sagen ich bin anfänger was scriptn betrifft, aber nicht lernfaul).
Fenryr
Grüße,
due müsstest dich auf die IP verlassen was gut schief laufen kann - gib die zeit lieber nach greenwitch an und beite die funktion die zeitzone zu wählen - weeesnetlich zuverlässiger.
MFG
bleicher
hi,
Ist es möglich ein Script so anzupassen und wie sieht soetwas aus(muss sagen ich bin anfänger was scriptn betrifft, aber nicht lernfaul).
Bei RIPE mal gucken, ob es eine geographische Beziehung zur IP gibt. Eine weitere Möglichkeit bestünde darin, die Zeitzone des Browsers im DOM abzufragen (mit ajax zum server). Und wenn Du dann noch dem Besucher die Möglichkeit gibst, seine Zeitzone selbst einstellen/korrigieren zu können (das kann dann in einem Cookie gespeichert werden) sollte es einigermaßen machbar und benutzerfreundlich sein.
Hotti
Hallo,
Ist es möglich eine Funktion umzusetzen, die es ermöglicht Zeiten anhand der IP zusteuern?
kurze Antwort: Nein.
Im Sendeplan wird 9 Uhr angezeigt, nun ist aber ein User aus der USA auf der Seite, der liest dann auch 9Uhr.
Das kannst du aber anhand der IP nicht wissen.
Das möchte ich eigentlich umgehen, so das der User den Sendungsbeginn sieht anhand seines IP-Standortes.
Dieses wäre als Beispiel dann 4Uhr.
Ist es möglich ein Script so anzupassen und wie sieht soetwas aus(muss sagen ich bin anfänger was scriptn betrifft, aber nicht lernfaul).
Es gibt zwar verschiedene Möglichkeiten, die IP-Adresse einem Ort oder Land zuzuordnen. Du könntest abfragen, welchem Unternehmen diese IP-Adresse "gehört" und wo dieses Unternehmen ansässig ist. Du könntest auch Datenbanken abfragen, die behaupten, eine IP/Ort-Zuordnung herzustellen. Letztendlich ist das aber mit einer großen Unsicherheit behaftet.
Da gibt es zum Beispiel Unternehmen, die ihren Sitz in den USA haben, und auch ihre Niederlassungen in Europa über die Firmenzentrale routen. Ergebnis: Du glaubst, du hättest einen Besucher aus den USA, obwohl er in Duisburg sitzt.
Oder denk an private Surfer, die der vermeintlichen Anonymität wegen einen Proxy benutzen. Du glaubst, du hättest einen Besucher aus der Ukraine, dabei sitzt er in Kopenhagen.
Oder einen deutschen Urlauber, der noch in Miami ist, sich aber im Internet-Café schon informieren will, was in der Woche seiner Heimreise in DE geboten wird. Du siehst einen Besucher aus den USA, der will die Zeiten aber trotzdem in MEZ sehen.
Dazu kommt, dass jemand, dem eine IP-Adresse zugeteilt wurde, jederzeit beschließen könnte, diese an einen ganz anderen Standort zu routen.
Nein, aus der IP-Adresse auf den Ort zu schließen, kann funktionieren - sinnvoll ist es aber oft nicht, und die Fehlerquote ist hoch.
So long,
Martin
@@Fenryr:
nuqneH
Im Sendeplan wird 9 Uhr angezeigt, nun ist aber ein User aus der USA auf der Seite, der liest dann auch 9Uhr.
Das möchte ich eigentlich umgehen, so das der User den Sendungsbeginn sieht anhand seines IP-Standortes.
Was hat die IP-Adresse mit der Zeitzone zu tun?
An die Zeitzone auf dem System des Nutzers kommst du per JavaScript: [ref:self812;javascript/objekte/date.htm#get_timezone_offset@title=getTimezoneOffset()]
Gib im HTML-Quelltext alle Zeiten in UTC an und rechne per JavaScipt um! Vergiss nicht, die letztendlich verwendete Zeitzone anzuzeigen!
Qapla'
Moin Moin!
An die Zeitzone auf dem System des Nutzers kommst du per JavaScript:
[ref:self812;javascript/objekte/date.htm#get_timezone_offset@title=getTimezoneOffset()]
Nein, ganz spitzfindig gesagt kommst Du damit nur an den Offset der Zeitzone heran, mit eingerechnet sind da schon Garstigkeiten wie z.B. die Sommerzeit. Der Offset basiert auf der Zeitzone, ist aber nicht die Zeitzone.
Vergiss nicht, die letztendlich verwendete Zeitzone anzuzeigen!
Genau das geht mit der minimalen Information, die Du aus dem Date-Objekt herausziehen kannst, nicht. Du kannst bestenfalls den Offset anzeigen. Wenn Du Zeitzonen-Namen / -Abkürzungen anzeigen willst, muß der Benutzer vorher zwingend eine Zeitzone ausgewählt haben. Allein aus dem Offset eine Zeitzone zu raten geht fast genauso schief wie die Zeitzone aus der IP-Adresse zu raten.
Es sei denn, Du kennst einen Weg, dem Browser die Zeitzone zu entlocken, die im Betriebssystem eingestellt ist.
Alexander
@@Alexander (HH):
nuqneH
Nein, ganz spitzfindig gesagt kommst Du damit nur an den Offset der Zeitzone heran, mit eingerechnet sind da schon Garstigkeiten wie z.B. die Sommerzeit. Der Offset basiert auf der Zeitzone, ist aber nicht die Zeitzone.
Das ist aber wirklich spitzfindig. Für mich ist "-05:00" die Angabe einer Zeitzone.
Natürlich wäre es möglich, je nach Datum daraus "EST" (Eastern Standard Time) oder "CDT" (Central Daylight Time) zu machen, aber was soll ein Südamerikaner mit den Kürzeln anfangen?
Wäre "+01:00" als "CET" oder "MEZ" anzugeben?
Und als Europäer wüsste ich – selbst wenn mir "EST" als Kürzel für Eastern Standard Time bekannt wäre – nicht unbedingt, wieviel Stunden Unterschied zur UTC das sind und müsste das erst nachschlagen.
Insbesondere auf Seiten für ein internationales Publikum sollten solche Kürzel vermieden und die Zeitzone als Offset angegeben werden. “[Abbreviations] are not part of the international time and date standard ISO 8601 and their use as sole designator for a time zone is not recommended.” [Wikipedia]
Qapla'
Hallo,
Neben dem was die anderen schon schrieben:
Im Sendeplan wird 9 Uhr angezeigt, nun ist aber ein User aus der USA auf der Seite, der liest dann auch 9Uhr.
Das möchte ich eigentlich umgehen, so das der User den Sendungsbeginn sieht anhand seines IP-Standortes.
Dieses wäre als Beispiel dann 4Uhr.
Nein, nicht zwingend: in den USA gibt es nicht nur eine Zeitzone. Selbst wenn du von einer IP sicher wüsstest, dass sie zu einem der dortigen Provider gehört, könntest du darauf noch nicht auf die Zeitzone schließen (und nein, der Versuch die IP einer Stadt zuzuordnen dürfte dort noch gründlicher schief gehen als hier).
Gruß,
Tobias
Moin Moin!
Wenn Du Dich darauf einläßt, Javascript vorauszusetzen, rechne komplett in UTC, und lasse eine JS-Funktion UTC auf dem Client in lokale Zeit umrechnen - und ggf. auch umgekehrt. Typischerweise stimmt die Zeitzoneneinstellung im Browser, und falls nicht, ist der jeweilige Anwender ohnehin Kummer gewohnt.
JS hat praktischerweise schon ein passendes Date-Objekt, dass Du mit den Millisekunden seit 1970-01-01 00:00:00.000 UTC initialisieren kannst, und aus dem Du diese Definition auch wieder rausholen kannst.
Als halbwegs fallback-taugliche Lösung könntest Du serverseitig die Zeiten in UTC als String ausgeben, zusätzlich "irgendwo" die Zeit als Timestamp ins Dokument schreiben und dann per JS den String durch durch die lokale Zeit ersetzen.
Ansatz:
<span class="utctimestamp" title="1294179332">2011-01-04 22:15:32 UTC</span>
(Einzig häßlicher Seiteneffekt: das Mini-Popup mit der "wirren" Zahl. Für das span-Element gibt es offenbar kein "nutzloses" Attribut wie rel.)
Dazu etwas jQuery o.ä.:
// ungetestet
$(document).ready(function() {
$('span.utctimestamp').each(function() {
var d=new Date(parseInt(this.title));
this.innerHTML=d.toLocaleString();
this.title='';
});
});
Date-Objekte kann man auch direkt mit einem passend formatierten String initialisieren, wenn Du den (und nur den) in das Dokument einbaust, kannst Du dir das extra-Attribut mit dem Timestamp sparen:
<span class="utctimestamp">Jan 4, 2011 22:15:32</span>
Entsprechend kürzer ist das Javascript:
// ungetestet
$(document).ready(function() {
$('span.utctimestamp').each(function() {
var d=new Date(this.innerHTML);
this.innerHTML=d.toLocaleString();
});
});
Alexander
Hi,
<span class="utctimestamp" title="1294179332">2011-01-04 22:15:32 UTC</span>
>
> (Einzig häßlicher Seiteneffekt: das Mini-Popup mit der "wirren" Zahl. Für das span-Element gibt es offenbar kein "nutzloses" Attribut wie rel.)
class darf auch 2 (oder noch mehr) Klassennamen enthalten. Klassennamen können auch rein numerisch sein.
cu,
Andreas
--
[Warum nennt sich Andreas hier MudGuard?](http://MudGuard.de/)
[O o ostern ...](http://ostereier.andreas-waechter.de/)
Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
Moin Moin!
<span class="utctimestamp" title="1294179332">2011-01-04 22:15:32 UTC</span>
> >
> > (Einzig häßlicher Seiteneffekt: das Mini-Popup mit der "wirren" Zahl. Für das span-Element gibt es offenbar kein "nutzloses" Attribut wie rel.)
>
> class darf auch 2 (oder noch mehr) Klassennamen enthalten.
Stimmt auffallend. Allerdings muß man sich dann den Timestamp erst einmal aus den Klassennamen herausfischen. Selbst jQuery scheint keinen Weg zu kennen, sich eine Liste aller Klassen eines Elementes geben zu lassen. addClass(), hasClass(), removeClass(), toggleClass() gibt es, aber kein getClasses() oder getClassNames().
Steht der Timestamp solo in einem "nutzlosen" Attribut, kann man sich das sparen.
Gab's nicht in irgendeinem antiken IE Probleme, wenn man mit mehr als einer Klasse arbeitete? Oder waren die Probleme auf CSS-Definitionen beschränkt?
> Klassennamen können auch rein numerisch sein.
Und selbst wenn nicht, kann man eine feste Zeichenfolge voranstellen. t oder utc böten sich an.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
Hallo,
Gab's nicht in irgendeinem antiken IE Probleme, wenn man mit mehr als einer Klasse arbeitete?
nicht generell; aus HTML- oder Javascript-Sicht war das nie ein Thema.
Oder waren die Probleme auf CSS-Definitionen beschränkt?
Ja, das war "nur" ein Problem, wenn man einen Selektor auf zwei oder mehr Klassennamen setzen wollte. Alte IEs haben dann nur den ersten Klassennamen beachtet.
Ob das Adjektiv "alt" und die Vergangenheitsform hier angebracht ist, weiß ich allerdings nicht.
Ciao,
Martin
Hi,
Ja, das war "nur" ein Problem, wenn man einen Selektor auf zwei oder mehr Klassennamen setzen wollte. Alte IEs haben dann nur den ersten Klassennamen beachtet.
oder wenn man ID- und Klassenselektor kombinierte: Das ging nur ein Mal pro Stylesheet, alle weiteren Regeln dieser Art wurden ignoriert.
Cheatah
@@Der Martin:
nuqneH
Ja, das war "nur" ein Problem, wenn man einen Selektor auf zwei oder mehr Klassennamen setzen wollte. Alte IEs haben dann nur den ersten Klassennamen beachtet.
Nein, den letzten.
Ob das Adjektiv "alt" und die Vergangenheitsform hier angebracht ist, weiß ich allerdings nicht.
Das Adjektiv „alt“ ist mit Sicherheit angebracht; IE 6 _ist_ alt.
Die Vergangenheitsform ist IMHO auch angebracht; IE 6 sollte in freier Wildbahn kaum noch anzutreffen sein. Obwohl man von störrischen Zielgruppen munkeln hört.
Qapla'
Hello,
Das Adjektiv „alt“ ist mit Sicherheit angebracht; IE 6 _ist_ alt.
Der müsste ja jetzt schon in der fünften Klasse sein. Aber ich glaube, er ist ein paarmal sitzengeblieben ;-P
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Moin Moin!
Das Adjektiv „alt“ ist mit Sicherheit angebracht; IE 6 _ist_ alt.
Der müsste ja jetzt schon in der fünften Klasse sein. Aber ich glaube, er ist ein paarmal sitzengeblieben ;-P
Der IE6 ist nie versetzt worden, selbst für die Sonderschule zu blöd, daher jetzt in der Baumschule. Alle Klassenkameraden warten schon längst auf Knut, nur den IE6 wollte niemand mehr haben. Wieder mal nicht versetzt.
Alexander
Hi,
Der müsste ja jetzt schon in der fünften Klasse sein. Aber ich glaube, er ist ein paarmal sitzengeblieben ;-P
Der IE6 ist nie versetzt worden, selbst für die Sonderschule zu blöd, daher jetzt in der Baumschule.
man munkelt, er spezialisiert sich derzeit auf Purzelbäume. Beim Klettern ist er wohl zu oft abgestürzt und hat sich das Layout verstaucht.
Cheatah
Der IE6 ist nie versetzt worden, selbst für die Sonderschule zu blöd, daher jetzt in der Baumschule.
man munkelt, er spezialisiert sich derzeit auf Purzelbäume. Beim Klettern ist er wohl zu oft abgestürzt und hat sich das Layout verstaucht.
Mir war schon immer klar, das "hasLayout" ein Tippfehler ist, es muss eigentlich "hatesLayout" heißen...
Gruß, LX
Moin,
Ob das Adjektiv "alt" und die Vergangenheitsform hier angebracht ist, weiß ich allerdings nicht.
Das Adjektiv „alt“ ist mit Sicherheit angebracht; IE 6 _ist_ alt.
Die Vergangenheitsform ist IMHO auch angebracht; IE 6 sollte in freier Wildbahn kaum noch anzutreffen sein. Obwohl man von störrischen Zielgruppen munkeln hört.
okay, ich wusste nicht, ob dieses Problem im 7er oder gar im 8er immer noch existiert, daher meine Unsicherheit.
Ciao,
Martin
Hi,
IE 6 sollte in freier Wildbahn kaum noch anzutreffen sein.
das kann ich leider, leider nicht bestätigen. Auf einem Portal mit recht "allgemeiner" Zielgruppe messen wir noch immer 2-4% IE6-Nutzer, der Fehler in der Messung dürfte gering sein. Wie immer kann diese Statistik schwerlich auf andere Fälle übertragen werden; für mich sagt sie jedoch aus, dass in Deutschland noch immer viele hunderttausend IE6-Nutzer umherschwirren.
Cheatah
@@Alexander (HH):
nuqneH
Als halbwegs fallback-taugliche Lösung könntest Du serverseitig die Zeiten in UTC als String ausgeben, zusätzlich "irgendwo" die Zeit als Timestamp ins Dokument schreiben und dann per JS den String durch durch die lokale Zeit ersetzen.
Ansatz:
<span class="utctimestamp" title="1294179332">2011-01-04 22:15:32 UTC</span>
Nö, nicht „irgendwo“. HTML5 bietet dafür mit 'time' ein passendes Element samt passendem Attribut '@datetime' (falls nötig). [HTML5 §4.6.10]
<time datetime="2011-01-04T22:15:32Z">2011-01-04 22:15:32 UTC</time> oder <time>2011-01-04T22:15:32Z</time>
Daraus kann man dann mit JavaScript
<time datetime="2011-01-04T22:15:32Z">2011-01-04 23:15:32 +01:00</time> bzw. <time>2011-01-04T23:15:32+01:00</time>
machen (wenn getTimezoneOffset() -60 liefert); auch ohne Framework per document.getElementsByTagName('time').
Äußerst sinnvoll dürfte hier auch die Verwendung von Mikroformaten (bzw. RDFa) sein:
<table class="vcalendar">
<tbody>
<tr class="vevent">
<th><time class="dtstart" datetime="2011-01-04T22:15:32Z">2011-01-04 22:15:32 UTC</time></th>
<td class="summary">Zeitenumrechnung anhand der IP</td>
</tr>
<!-- weitere Sendungen -->
</tbody>
</table>
Oder, falls man noch kein HTML5 verwenden möchte:
<table class="vcalendar">
<tbody>
<tr class="vevent">
<th><abbr class="dtstart" title="2011-01-04T22:15:32Z">2011-01-04 22:15:32 UTC</abbr></th>
<td class="summary">Zeitenumrechnung anhand der IP</td>
</tr>
<!-- weitere Sendungen -->
</tbody>
</table>
(Einzig häßlicher Seiteneffekt: das Mini-Popup mit der "wirren" Zahl. Für das span-Element gibt es offenbar kein "nutzloses" Attribut wie rel.)
Ja, und der Missbrauch des 'abbr'-Elements ist mehr als nur hässlich.
Qapla'
Hi,
<span class="utctimestamp" title="1294179332">2011-01-04 22:15:32 UTC</span>
>
> Für das span-Element gibt es offenbar kein "nutzloses" Attribut wie rel.
Parallel zu dem was Gunnar bzgl. des time-Elements erwähnt hat: Bitte erwähne, wenn du Daten in dazu nicht passenden Attributen speichern willst, wenigstens die Möglichkeit von HTML5, die Daten in einem eigenen Attribut (mit dem Prefix "-data-") unterzubringen.
Wenn es kein passendes HTML-Element für solche Daten gibt, ist das Speichern in "-data-\*"-Attributen i.d.R. deutlich unproblematischer als das Speichern in fremden Attributen.
Bis die Tage,
Matti
--
[Webapplikationen in C++ entwickeln](http://tntnet.org/)
Hi,
[...] in einem eigenen Attribut (mit dem Prefix "-data-") unterzubringen.
Prefix "data-", nicht "-data-".
Cheatah