pl: Angabe der Zeitzone

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

  1. 0050 == halbe Stunde?
  2. 0050 == 50 Minuten?

MfG und Danke im vorab.

  1. 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

    1. @@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 🖖

      --
      “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
  2. @@pl

    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

    Wie at sagte: vermutlich Minuten.

    1. 0050 == halbe Stunde?
    2. 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 🖖

    --
    “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
    1. +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?

      1. halbe?
      2. viertel?

      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.

      1. @@pl

        Ja, schön. Und wie sähe das aus in den letzen beiden Digits?

        1. halbe?
        2. 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 🖖

        --
        “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
        1. Es wird auf RFC 822 verwiesen. In 5. DATE AND TIME SPECIFICATION wird die Bedeutung der Ziffern genannt.

          Also HHMM, danke Dir. MfG

        2. 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

          1. Moin,

            im ATOM-Feed steht es eindeutig(er):

            <updated>2017-09-12T08:49:55+02:00</updated>
            

            Viele Grüße
            Robert

            1. 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

              1. @@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 +0200 zu 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 🖖

                --
                “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
                1. @@Gunnar Bittersmann

                  Wie wärs denn mit UTC als UNIX-Timestamp? Inwiefern sollte Sun, 10 Sep 2017 15:16:49 +0000 einfacher 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 +0200 zu parsen.

                  Der UNIX-Timestamp ist für Menschen schwer zu parsen.

                  „UTC als UNIX-Timestamp“ – wie bitte? Beides zusammen macht überhaupt keinen Sinn.

                  LLAP 🖖

                  --
                  “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
                2. 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

                  1. @@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 🖖

                    --
                    “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
                    1. 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

                      1. @@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 🖖

                        --
                        “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
                        1. @@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

                        2. 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

                          1. @@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 🖖

                            --
                            “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
                            1. 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

                      2. 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

                        1. 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:

                          1. Berechnung der Anzahl der seit dem 1.1.1970 (Beginn der Epoche) vergangenen Tage aus dem Datum (Tag, Monat, Jahr), daraus ergibt sich die Anzahl der Sekunden,
                          2. Berechnung der Anzahl der abgelaufenen Sekunden des jeweiligen Tages anhand der Stunde, Minute, Sekunden Angabe,
                          3. Zeitzone vorzeichenbehaftet in Sekunden umrechnen und je nach Vorzeichen zum bisher ermittelten Zeitstempel addieren oder davon abziehen.

                          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

                          1. 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

                            1. 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 😉

                          2. @@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 🖖

                            --
                            “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
                            1. Hallo,

                              In welchem Paralleluniversum wäre das der Fall?

                              reine Vermutung: Perl?

                              Gruß
                              Kalk

                            2. @@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 😉

                            3. 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

                              1. 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 +0200 in 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

                                1. Mächtig, gewaltig 😉

                                  Danke!

                                2. @@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 🖖

                                  --
                                  “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
                                  1. 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

                          3. 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

                            1. 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

                              1. Das steht doch in dem zitierten Block.

                                1. 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

                                  1. 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

                                    1. 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

                                  2. 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

                                    --
                                    Dosen sind silbern
                                    1. 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

                                      1. 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

                                        --
                                        Dosen sind silbern
                                        1. Hallo Rolf,

                                          Und dein Beitrag enthält den Link noch…

                                          Jain. Ich war einfach noch nicht fertig 😀

                                          LG,
                                          CK

                                    2. 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