nicht angemeldet at
Gunnar Bittersmann
Gunnar Bittersmann
Robert B.
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
Tabellenkalk
Robert B.
S. Thema, Fri, 08 Sep 2017 21:07:52 +0200 ist klar, 02 heißt 2 Stunden. Was jedoch würden die letzten beiden Digits bedeuten, Minuten oder einen Bruch, also
MfG und Danke im vorab.
Hallo pl,
das kann dir derjenige sagen, der das fabriziert hat. ISO 8601 sieht entweder +02:00 oder +02 vor. Ich vermute aber, dass da einfach ein Doppelpunkt weggelassen wurde und die letzten Stellen für Minuten stehen.
MfG, at
@@at
ISO 8601 sieht entweder +02:00 oder +02 vor.
Nö; auch +0200.
In der deutschen Wikipedia ist das vage gehalten: „Für jedes Format existiert eine kurze Version mit einer minimalen Anzahl von Trennzeichen und eine erweiterte Version, die weitere Trennzeichen zur besseren menschlichen Lesbarkeit enthält.“
In der englischen Wikipedia wird’s deutlicher: „in the form ±[hh]:[mm], ±[hh][mm], or ±[hh]. So if the time being described is one hour ahead of UTC (such as the time in Berlin during the winter), the zone designator would be "+01:00", "+0100", or simply "+01".“
LLAP 🖖
@@pl
S. Thema,
Fri, 08 Sep 2017 21:07:52 +0200ist klar, 02 heißt 2 Stunden. Was jedoch würden die letzten beiden Digits bedeuten, Minuten oder einen Bruch
Wie at sagte: vermutlich Minuten.
- 0050 == halbe Stunde?
- 0050 == 50 Minuten?
+0050 oder −0050 sollte es aber nicht geben, da Zonenzeiten volle, halbe oder Viertelstunden von UTC abweichen. (Zumindest gegenwärtig ist das so.)
LLAP 🖖
+0050 oder −0050 sollte es aber nicht geben, da Zonenzeiten volle, halbe oder Viertelstunden von UTC abweichen. (Zumindest gegenwärtig ist das so.)
Ja, schön. Und wie sähe das aus in den letzen beiden Digits?
MfG
PS: Zeitangaben dieser Art sind übrigens von eurem RSS Feed
<pubDate>Mon, 11 Sep 2017 20:14:06 +0200</pubDate>
und ansonsten in jeder Mail zu finden.
@@pl
Ja, schön. Und wie sähe das aus in den letzen beiden Digits?
- halbe?
- viertel?
Wie in verlinkten Artikel gesagt. Links zu folgen ist nicht dein Ding?
PS: Zeitangaben dieser Art sind übrigens von eurem RSS Feed
<pubDate>Mon, 11 Sep 2017 20:14:06 +0200</pubDate>
Bei RSS müsstest du eigentlich schon die Version angeben. Nach „rss specification“ zu suchen ist nicht dein Ding?
Es wird auf RFC 822 verwiesen. In 5. DATE AND TIME SPECIFICATION wird die Bedeutung der Ziffern genannt.
LLAP 🖖
Es wird auf RFC 822 verwiesen. In 5. DATE AND TIME SPECIFICATION wird die Bedeutung der Ziffern genannt.
Also HHMM, danke Dir. MfG
Bei RSS müsstest du eigentlich schon die Version angeben.
Ich sehe hier im Forum nur einen RSS Feed und der hat Version 2.0
MfG
Moin,
im ATOM-Feed steht es eindeutig(er):
Rolf B<updated>2017-09-12T08:49:55+02:00</updated>
Viele Grüße
Robert
im ATOM-Feed steht es eindeutig(er):
Naja, unter Eindeutigkeit verstehe ich was Anderes. Wie wärs denn mit UTC als UNIX-Timestamp? Aus einem Solchen die Lokale Zeit wiederherzustellen ist doch viel einfacher als einen String Sun, 10 Sep 2017 17:16:49 +0200 zu parsen. Wobei die Umrechnung ohnehin über UNIXTimestamp vonstatten geht. Idealerweise würde ein Feed allesamt mitbringen aber schön voneinander getrennt, dann hats auch der Client einfacher mit der Erzeugung von Custom Formaten.
MfG
@@pl
Wie wärs denn mit UTC als UNIX-Timestamp? Aus einem Solchen die Lokale Zeit wiederherzustellen ist doch viel einfacher als einen String
Sun, 10 Sep 2017 17:16:49 +0200zu parsen.
Inwiefern sollte Sun, 10 Sep 2017 15:16:49 +0000 einfacher zu parsen sein als Sun, 10 Sep 2017 17:16:49 +0200?
LLAP 🖖
@@Gunnar Bittersmann
Wie wärs denn mit UTC als UNIX-Timestamp? Inwiefern sollte
Sun, 10 Sep 2017 15:16:49 +0000einfacher zu parsen sein …?
Das war die Antwort auf den UTC-Teil in deiner Frage.
Aus einem Solchen die Lokale Zeit wiederherzustellen ist doch viel einfacher als einen String
Sun, 10 Sep 2017 17:16:49 +0200zu parsen.
Der UNIX-Timestamp ist für Menschen schwer zu parsen.
„UTC als UNIX-Timestamp“ – wie bitte? Beides zusammen macht überhaupt keinen Sinn.
LLAP 🖖
Inwiefern sollte Sun, 10 Sep 2017 15:16:49 +0000 einfacher zu parsen sein als Sun, 10 Sep 2017 17:16:49 +0200?
Da hast Du was falsch verstanden, denn das war gar nicht die Frage. Was ich meinte ist, die Daten nämlich so zu liefern dass sie gar nicht mehr geparst werden müssen. Womit sie am Client für jedes beliebige Format einfach nur noch zusammengesetzt werden müssen. Und auf diese Art und Weise können ja auch Timestamp und Zeitzone ein extra Datenfeld bekommen (für die Übertragung). MfG
@@pl
Was ich meinte ist, die Daten nämlich so zu liefern dass sie gar nicht mehr geparst werden müssen.
Kann man machen, ist dann nur für Menschen nicht mehr lesbar.
Und auf diese Art und Weise können ja auch Timestamp und Zeitzone ein extra Datenfeld bekommen (für die Übertragung).
?? Ein Timestamp hat keine Zeitzone.
LLAP 🖖
Was ich meinte ist, die Daten nämlich so zu liefern dass sie gar nicht mehr geparst werden müssen.
Kann man machen, ist dann nur für Menschen nicht mehr lesbar.
Man kann sie aber so zusammensetzen dass sie lesbar sind! Und vor allem sollte man den Monat numerisch liefern und nicht als Abkürzung.
Und auf diese Art und Weise können ja auch Timestamp und Zeitzone ein extra Datenfeld bekommen (für die Übertragung).
?? Ein Timestamp hat keine Zeitzone.
Ein Timestamp selber nicht aber man sollte schon wissen ob der gmtime oder localtime präsentiert. Also braucht man schon die Zeitzone. Wozu wird sie denn bei Eurem Forumsfeed mitgeliefert?
MfG
@@pl
Was ich meinte ist, die Daten nämlich so zu liefern dass sie gar nicht mehr geparst werden müssen.
Damit meintest du Unix-Timestamp.
Kann man machen, ist dann nur für Menschen nicht mehr lesbar Man kann sie aber so zusammensetzen dass sie lesbar sind! Und vor allem sollte man den Monat numerisch liefern und nicht als Abkürzung.
Ein Unix-Timestamp hat keinen Monat.
?? Ein Timestamp hat keine Zeitzone. Ein Timestamp selber nicht aber man sollte schon wissen ob der gmtime oder localtime präsentiert.
Sollte man? Weiß der Nutzer (dessen Client) nicht am besten, in welcher Zonenzeit er einen Zeitpunkt angezeigt bekommen möchte?
Also braucht man schon die Zeitzone. Wozu wird sie denn bei Eurem Forumsfeed mitgeliefert?
Weil das kein Unix-Timestamp ist und man bei einer Uhrzeit schon wissen muss, in welcher Zonenzeit diese angegeben ist.
LLAP 🖖
@@pl
Was ich meinte ist, die Daten nämlich so zu liefern dass sie gar nicht mehr geparst werden müssen.
Damit meintest du Unix-Timestamp.
Nein, ich meine alles zusammen. Beispiel in XML:
<date day='01' month='01' year='1970' tz='7200' hour='0' min='0' sec='0'>7200</date>
Wobei day, month, year auch dedizierte Elemente (Datenfelder) sein können. Und mit diesen Angaben, die bereits der XML-Parser liefert, kannste Datum und Uhrzeit in jedem gewünschten Format darstellen. Natürlich sind die Daten redundant, aber auf ein Datenfeld mehr oder weniger kommt es ja nicht an. Der UnixTimestamp wird gebraucht für eine etwaige eigene maschinelle Weiterverarbeitung. So wäre alles griffbereit und würde Einiges an clientseitigem Programmieraufwand sparen. MfG
Hallo Gunnar,
Weil das kein Unix-Timestamp ist und man bei einer Uhrzeit schon wissen muss, in welcher Zonenzeit diese angegeben ist.
Ein Unix-Timestamp ist per Definition (POSIX-Standard) die Anzahl Sekunden seit dem 1.1.1970 00:00 UTC (ohne die Schaltsekunden). Die Zeitzone ist also in der Definition enthalten.
Nichtsdestotrotz ist die UNIX-Zeit ein schlechtes Format, um Uhrzeiten anzugeben, ja.
LG,
CK
@@Christian Kruse
Ein Unix-Timestamp ist per Definition (POSIX-Standard) die Anzahl Sekunden seit dem 1.1.1970 00:00 UTC (ohne die Schaltsekunden). Die Zeitzone ist also in der Definition enthalten.
Die Anzahl Sekunden – also der Timestamp – enthält keine Zeitzone.
Die Angabe der Uhrzeit des Startzeitpunkts enthält die Angabe der darin verwendeten Zeitzone, natürlich.
LLAP 🖖
Hallo Gunnar,
Ein Unix-Timestamp ist per Definition (POSIX-Standard) die Anzahl Sekunden seit dem 1.1.1970 00:00 UTC (ohne die Schaltsekunden). Die Zeitzone ist also in der Definition enthalten.
Die Anzahl Sekunden – also der Timestamp – enthält keine Zeitzone.
Die Angabe der Uhrzeit des Startzeitpunkts enthält die Angabe der darin verwendeten Zeitzone, natürlich.
Sag ich doch. Die Zeitzone ist in der Definition enthalten. Du musst mir nicht widersprechen um mir zu widersprechen 😉
LG,
CK
Hallo pl,
Wozu wird sie denn bei Eurem Forumsfeed mitgeliefert?
Weil das im Standard so verlangt wird. Entweder in Form eines Kürzels oder als Offset von UTC. Und dort ist auch definiert, dass der Doppelpunkt beim Offset wegfallen muss. Lies es doch einfach mal nach, RSS ist ein offener Standard und dort wird auf RFC 822 verwiesen. Die sagt über die Zeitangabe:
time = hour zone ; ANSI and Military
hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT]
; 00:00:00 - 23:59:59
zone = "UT" / "GMT"
/ "EST" / "EDT"
/ "CST" / "CDT"
/ "MST" / "MDT"
/ "PST" / "PDT"
/ 1ALPHA
/ ( ("+" / "-") 4DIGIT )
LG,
CK
Hallo pl,
Wozu wird sie denn bei Eurem Forumsfeed mitgeliefert?
Weil das im Standard so verlangt wird.
Und dieser Standard ist eben schlecht. Wie ich hier in diesem Thread mehrfach darlegte, ist er deswegen schlecht, weil Einiges an programmiertechnischen Aufwand getrieben werden muss wenn andere Ausgabeformate erzeugt werden sollen oder der UnixTimestamp berechnet werden muss für eine eigene maschinelle Weiterverarbeitung. Zunächst wäre der Zeitstring zu parsen, um einen wahlfreien Zugriff auf die einzelnen Komponenten wie Tag, Monat, Jahr, Stunde, Minute, Sekunde zu bekommen. Zur Berechnung des Unixtimestamps ist folgendes zu tun:
Insbesondere (1) ist ziemlich aufwendig, wenn entsprechende Libraries nicht verfügbar sind. Der Witz ist ja der, dass zum Zeitpunkt der Erzeugung eines Feed die einzelnen Komponenten im wahlfreien Zugriff sind und so auch in eizelnen XML-Elementen (oder Attributen) verpackt und transportiert werden könnten. Siehe auch hier da geht es sinngemäß um genau dasselbe Thema. MfG
Hallo pl,
Wozu wird sie denn bei Eurem Forumsfeed mitgeliefert?
Weil das im Standard so verlangt wird.
Und dieser Standard ist eben schlecht.
Wen interessierts? Es ist der Standard, wenn ich RSS anbieten will muss ich mich also danach richten.
LG,
CK
Moin,
Wen interessierts? Es ist der Standard, wenn ich RSS anbieten will muss ich mich also danach richten.
Stimmt. Bei meiner Darstellung der Feeds ist die Zeitzone völlig uninteressant. Und zum Cachen brauche ich lediglich einen Zeitstempel nach dem sortiert werden kann, also auch da brauche ich die Zeitzone nicht, da genügen $sec, $min, $hour, $mday, $mon, $year zur Berechnung, da ist ein etwaiger Offset zum 1.1.1970 00:00:00 völlig wurscht 😉
@@pl
weil Einiges an programmiertechnischen Aufwand getrieben werden muss … wenn entsprechende Libraries nicht verfügbar sind.
In welchem Paralleluniversum wäre das der Fall?
LLAP 🖖
Hallo,
In welchem Paralleluniversum wäre das der Fall?
reine Vermutung: Perl?
Gruß
Kalk
@@pl
weil Einiges an programmiertechnischen Aufwand getrieben werden muss … wenn entsprechende Libraries nicht verfügbar sind.
In welchem Paralleluniversum wäre das der Fall?
Och verfügbar sind die schon, es ist nur die Frage ob ich gewillt bin, 1097 Dateien des Moduls DateTime auf meinen Webspace zu laden, nur um einen lumpigen String zu parsen 😉
hi,
weil Einiges an programmiertechnischen Aufwand getrieben werden muss … wenn entsprechende Libraries nicht verfügbar sind.
In welchem Paralleluniversum wäre das der Fall?
Mit welcher PHP Funktion kann man denn Sun, 10 Sep 2017 17:16:49 +0200 in einen Unix-Timestamp umwandeln? Mit der Bitte um ein nachvollziehbares Beispiel. MfG
Hallo pl,
weil Einiges an programmiertechnischen Aufwand getrieben werden muss … wenn entsprechende Libraries nicht verfügbar sind.
In welchem Paralleluniversum wäre das der Fall?
Mit welcher PHP Funktion kann man denn
Sun, 10 Sep 2017 17:16:49 +0200in einen Unix-Timestamp umwandeln? Mit der Bitte um ein nachvollziehbares Beispiel.
Gunnar sprach zwar eher davon, dass es prinzipiell nicht besonders aufwendig ist, so einen String zu parsen, aber in PHP gibt es da tatsächlich etwas fertiges:
var_dump(strtotime("Sun, 10 Sep 2017 17:16:49 +0200"));
var_dump(DateTime::createFromFormat(DateTime::RFC2822, "Sun, 10 Sep 2017 17:16:49 +0200")->getTimestamp());
LG,
CK
Mächtig, gewaltig 😉
Danke!
@@Christian Kruse
weil Einiges an programmiertechnischen Aufwand getrieben werden muss … wenn entsprechende Libraries nicht verfügbar sind.
Gunnar sprach zwar eher davon, dass es prinzipiell nicht besonders aufwendig ist, so einen String zu parsen
Nö, das meinte ich nicht, sondern dass es wohl für alle Sprachen entsprechende Datum/Zeit-Bibliotheken gibt. Für PHP bspw. genau das, was du sagtest.
LLAP 🖖
Hallo Gunnar,
weil Einiges an programmiertechnischen Aufwand getrieben werden muss … wenn entsprechende Libraries nicht verfügbar sind.
Gunnar sprach zwar eher davon, dass es prinzipiell nicht besonders aufwendig ist, so einen String zu parsen
Nö, das meinte ich nicht, sondern dass es wohl für alle Sprachen entsprechende Datum/Zeit-Bibliotheken gibt.
Du hast natürlich recht. Man will sowas nicht von Hand parsen, zu viele Fehlerquellen, zu viele Sachen, die es zu beachten gibt. Ich verlinke bei sowas immer gern dieses Video von Computerphile.
LG,
CK
Moin pl,
die Frage ist doch, muss ich diesen Aufwand des Parsens und der Berechnung überhaupt betreiben oder reicht einfach der simple Vergleich des Datumsstrings im Feed mit dem der Serverantwort?
Viele Grüße
Robert
die Frage ist doch, muss ich diesen Aufwand des Parsens und der Berechnung überhaupt betreiben oder reicht einfach der simple Vergleich des Datumsstrings im Feed mit dem der Serverantwort?
Was für einen Vergleich? MfG
Das steht doch in dem zitierten Block.
Abgesehen davon dass der Vergleich mit dem Datum in der Serverantwort alles andere als einfach ist, weil die Strings unterschiedlich formatiert sind und daher alles in einen Timestamp umgerechnet werden müsste, was soll denn so ein Vergleich bringen? MfG
Moin pl,
Abgesehen davon dass der Vergleich mit dem Datum in der Serverantwort alles andere als einfach ist, weil die Strings unterschiedlich formatiert sind und daher alles in einen Timestamp umgerechnet werden müsste, was soll denn so ein Vergleich bringen?
ein simples Serverprogramm würde die Zeit der letzten Aktualisierung des Feeds mit dem Wert vom Client vergleichen und bei Ungleichheit den Feed ausliefern, andernfalls einen HTTP-Status 204. Das ist doch nicht so schwierig.
Viele Grüße
Robert
Moin pl,
Abgesehen davon dass der Vergleich mit dem Datum in der Serverantwort alles andere als einfach ist, weil die Strings unterschiedlich formatiert sind und daher alles in einen Timestamp umgerechnet werden müsste, was soll denn so ein Vergleich bringen?
ein simples Serverprogramm würde die Zeit der letzten Aktualisierung des Feeds mit dem Wert vom Client vergleichen und bei Ungleichheit den Feed ausliefern, andernfalls einen HTTP-Status 204. Das ist doch nicht so schwierig.
Das Cachen habe ich viel einfacher gelöst: Der ganze Feed wird, sofern so konfiguriert, komplett auf meinem Server gespeichert. Der dem entsprechende Request wird beim Aufruf des Feeds asynchron abgekoppelt, der Feed für den Browser jedoch wird aus der lokalen Datei (oder MySQL) wiederhergestellt. Da wird nur geprüft, ob das cachen konfiguriert ist, wenn ja, gibt es einen DAL (Data Access Layer), untenstehend der Weg in den Cache:
# in Callbackfunktion die das Datum formatiert
# Cache, die items werden gespeichert
my $dal = $self->{DAL} || return $formdate;
$dal->checkin($ts, %$hunt);
return $formdate;
Und dann der Weg der Daten aus dem Cache wieder raus:
$self->{STASH}{feedslice} = $self->eav('file') ? do{
no warnings;
my $dal = $self->{DAL};
my @ents = sort{$b <=> $a}$dal->count;
my @sl = ();
foreach my $e( @ents ){
my $hunt = $dal->checkout($e);
push @sl, $hunt;
}
\\@sl;
} : $self->slicefeed($feed);
$self->{STASH}{feedtitle} = $cfg->{$feed}{title};
MfG
Hallo pl,
ich habe diesen Beitrag als SPAM gemeldet - der Link auf "Saschas Welt" als problematische Seite gehört da nun überhaupt nicht hinein.
Oder anders gesehen: Wenn Du Saschas politische Ansichten als "Problematisch" empfindest, warum hostest Du sie dann? 😉
Rolf
Hallo Rolf,
ich habe diesen Beitrag als SPAM gemeldet - der Link auf "Saschas Welt" als problematische Seite gehört da nun überhaupt nicht hinein.
Du hast recht. Ist mir gar nicht aufgefallen. Ich habe die Links mal entfernt.
LG,
CK
Hallo Christian,
du bist einfach zu schnell 😉. Und dein Beitrag enthält den Link noch...
Ich wollte in mein Posting noch hineineditieren, dass ich die SPAM-Meldung gelöscht habe, weil sich das auf Inhalt bezieht und das wäre falsch. Statt dessen habe ich meine Stimme zurückgezogen und dem Beitrag als "Sonstiges" mit Grund "Link-Spam" neu gemeldet, aber das Forum ändert die Anzeige nicht mehr. Darum sieht's jetzt merkwürdig aus, mit 0/5 Stimmen.
Rolf
Hallo Rolf,
Und dein Beitrag enthält den Link noch…
Jain. Ich war einfach noch nicht fertig 😀
LG,
CK
Hallo pl,
ich habe diesen Beitrag als SPAM gemeldet - der Link auf "Saschas Welt" als problematische Seite gehört da nun überhaupt nicht hinein.
Nun, das Problem ist ja gelöst. Übrigens sind meine gepufferten Feeds jeweils 10mal schneller geladen als der RSS Feed für dieses Forum.
MfG