Artwork

Inhalt bereitgestellt von Stefan Majewsky and Xyrillian Noises. Alle Podcast-Inhalte, einschließlich Episoden, Grafiken und Podcast-Beschreibungen, werden direkt von Stefan Majewsky and Xyrillian Noises oder seinem Podcast-Plattformpartner hochgeladen und bereitgestellt. Wenn Sie glauben, dass jemand Ihr urheberrechtlich geschütztes Werk ohne Ihre Erlaubnis nutzt, können Sie dem hier beschriebenen Verfahren folgen https://de.player.fm/legal.
Player FM - Podcast-App
Gehen Sie mit der App Player FM offline!

STP016: Zeitdarstellung

1:19:22
 
Teilen
 

Fetch error

Hmmm there seems to be a problem fetching this series right now. Last successful fetch was on February 13, 2025 23:12 (20d ago)

What now? This series will be checked again in the next day. If you believe it should be working, please verify the publisher's feed link below is valid and includes actual episode links. You can contact support to request the feed be immediately fetched.

Manage episode 322419862 series 2920733
Inhalt bereitgestellt von Stefan Majewsky and Xyrillian Noises. Alle Podcast-Inhalte, einschließlich Episoden, Grafiken und Podcast-Beschreibungen, werden direkt von Stefan Majewsky and Xyrillian Noises oder seinem Podcast-Plattformpartner hochgeladen und bereitgestellt. Wenn Sie glauben, dass jemand Ihr urheberrechtlich geschütztes Werk ohne Ihre Erlaubnis nutzt, können Sie dem hier beschriebenen Verfahren folgen https://de.player.fm/legal.

Heute brechen wir das fünfte Bit an. Das tun wir mit einem Thema, das scheinbar einfach ist, sich allerdings bei genauerer Betrachtung als tückisch herausstellt. Es geht um Zeit und ihre Darstellung. Und darum, dass es nicht immer sinnvoll ist, sich seinen eigenen Kalender auzudenken. Außerdem überzeugt ttimeless duch überragende Excel-Kentnisse.

Shownotes

  • Zeiteinteilung ist ganz schön unhandlich
    • Kalender orientieren sich an astronomischen Fakten, die leider keine schönen ganzzahligen Einteilungen erlauben (1 Sonnenjahr = 365,242... Tage, 1 Mondmonat = 29.530... Tage, etc.)
    • präzise Definition von kleinen Zeiteinheiten wie Sekunden zeigt, dass die astronomischen Fakten schwanken -> Schaltsekunden; später mehr
    • Zielkonflikt: möglichst gleichmäßige Zeitentwicklung oder möglichst intuitive Handhabung
    • Internationale Atomzeit (TAI): exakt gleichmäßig (im Rahmen der Genauigkeit der Atomuhr), berücksichtigt nicht Schwankungen in der Tageslänge durch Änderungen der Erdrotationsgeschwindigkeit
    • Koordinierte Weltzeit (UTC): TAI zuzüglich Schaltsekunden (zurzeit TAI = UTC + 37s), sodass der Tagesbeginn am nullten Breitengrad immer bei 00:00:00 Uhr UTC bleibt

Wie können Computer Zeit darstellen?

  • Option 1: separate Zahlen für Jahr, Monat, Tag, Stunde, Minute, Sekunde

    • Verwendung vor allem an Stellen, wo der Nutzer es sehen kann (Zeitanzeigen, Zeitstempel in Dateinamen etc.)
    • Vorteil: sofort menschenlesbar
    • Nachteil: muss für Eindeutigkeit immer mit Zeitzoneninformation verknüpft sein; Gültigkeit von zukünftigen Zeitangaben evtl. durch nicht vorhergesehene Zeitzonenänderungen beeinträchtigt
    • Nachteil: textuelle Darstellung je nach Kulturkreis uneindeutig (z.B. "4/7/2021" kann entweder für den 4. Juli oder den 7. April stehen)
  • Option 2: eine einzelne Zahl, die die vergangene Zeit in einer bestimmten Einheit (z.B. Sekunden oder Tage) seit einem Startzeitpunkt (der Epoche) angibt

    • z.B. Unix: Sekunden seit 1. Januar 1970 00:00:00 Uhr UTC (bzw. 01:00:00 Uhr deutscher Zeit)
    • z.B. julianisches Datum: Tage seit 1. Januar 4713 v.u.Z.
    • z.B. Excel, LibreOffice Calc, etc.: Tage seit 1. Januar 1900, mit Nachkommastellen für Zeitpunkte innerhalb eines Tages
  • Probleme durch Überlauf in Datumsfeldern

    • Y2K-Problem: Überlauf in der Jahreszahl, die damals zweistellig angegeben war (z.B. "76" für 1976)
    • Y2038-Problem: Überlauf in einem 32-Bit-Unix-Zeitstempel (am Dienstag, dem 19. Januar 2038 um 04:14:07 Uhr deutscher Zeit)
    • GPS-Wochen-Rollover: Überlauf in der Wochenzahl des Zeitstempel-Formats von GPS; erstmals 1999, zuletzt 2019, nächstes Mal 2038
  • Probleme durch astronomische/politische Fakten

    • Berechnungen wie "10 Tage dazuaddieren" mühselig aufgrund Kalenderregeln (Monatswechsel, Schalttage etc.)
      • Beispiel: in einer Terminserie wie "täglich um 15 Uhr" hat wegen Sommerzeitwechsel nicht jeder Termin genau 24 Stunden Abstand zueinander
      • Beispiel: Sommerzeitumstellung bei der Eisenbahn (diesen Abschnitt können wir im Prinzip direkt vorlesen)
    • Schaltsekunden lassen UTC springen und erzeugen unerwartete Zeitzustände wie "23:59:60"
    • Zeitzonendefinitionen folgen politischen Entscheidungen
      • z.B. Deutschland besteht in tzdata aus zwei Zeitzonen
      • z.B. 2015 Chaos in der Türkei durch eine Änderung der Sommerzeitregel mit zu wenig Vorlauf
  • Probleme durch technische Einflüsse

    • Hardware-Uhren sind nicht hinreichend genau und driften mit der Zeit: in verteilten Systemen mögliche Verwirrung über die Reihenfolge von Aktionen
    • Zeitsynchronisation mittels NTP (Network Time Protocol): im Moment der Richtigstellung der Uhr mögliche Verwirrung durch einen kleinen Sprung rückwärts in der Zeit
    • Suspend/Standby: im Moment des Wiederanschaltens mögliche Verwirrung durch einen drastischen Sprung vorwärts in der Zeit
    • monotonische Uhren: zählen die Zeit, die der Computer seit Systemstart gelaufen sind (z.B. mittels TSC; damit zuverlässige Messung von Laufzeitspannen etc.
  • positiver Ausblick: Es könnte noch viel schlimmer sein!

    • gregorianischer Kalender hat sich weltweit für den Geschäftsverkehr durchgesetzt
    • Beispiel für einen alternativen Kalender: Japanische Zeitrechnung
  • kryptografisch abgesicherte Zeitstempel: RFC Podcast #15 Crypto for the Masses

  continue reading

69 Episoden

Artwork
iconTeilen
 

Fetch error

Hmmm there seems to be a problem fetching this series right now. Last successful fetch was on February 13, 2025 23:12 (20d ago)

What now? This series will be checked again in the next day. If you believe it should be working, please verify the publisher's feed link below is valid and includes actual episode links. You can contact support to request the feed be immediately fetched.

Manage episode 322419862 series 2920733
Inhalt bereitgestellt von Stefan Majewsky and Xyrillian Noises. Alle Podcast-Inhalte, einschließlich Episoden, Grafiken und Podcast-Beschreibungen, werden direkt von Stefan Majewsky and Xyrillian Noises oder seinem Podcast-Plattformpartner hochgeladen und bereitgestellt. Wenn Sie glauben, dass jemand Ihr urheberrechtlich geschütztes Werk ohne Ihre Erlaubnis nutzt, können Sie dem hier beschriebenen Verfahren folgen https://de.player.fm/legal.

Heute brechen wir das fünfte Bit an. Das tun wir mit einem Thema, das scheinbar einfach ist, sich allerdings bei genauerer Betrachtung als tückisch herausstellt. Es geht um Zeit und ihre Darstellung. Und darum, dass es nicht immer sinnvoll ist, sich seinen eigenen Kalender auzudenken. Außerdem überzeugt ttimeless duch überragende Excel-Kentnisse.

Shownotes

  • Zeiteinteilung ist ganz schön unhandlich
    • Kalender orientieren sich an astronomischen Fakten, die leider keine schönen ganzzahligen Einteilungen erlauben (1 Sonnenjahr = 365,242... Tage, 1 Mondmonat = 29.530... Tage, etc.)
    • präzise Definition von kleinen Zeiteinheiten wie Sekunden zeigt, dass die astronomischen Fakten schwanken -> Schaltsekunden; später mehr
    • Zielkonflikt: möglichst gleichmäßige Zeitentwicklung oder möglichst intuitive Handhabung
    • Internationale Atomzeit (TAI): exakt gleichmäßig (im Rahmen der Genauigkeit der Atomuhr), berücksichtigt nicht Schwankungen in der Tageslänge durch Änderungen der Erdrotationsgeschwindigkeit
    • Koordinierte Weltzeit (UTC): TAI zuzüglich Schaltsekunden (zurzeit TAI = UTC + 37s), sodass der Tagesbeginn am nullten Breitengrad immer bei 00:00:00 Uhr UTC bleibt

Wie können Computer Zeit darstellen?

  • Option 1: separate Zahlen für Jahr, Monat, Tag, Stunde, Minute, Sekunde

    • Verwendung vor allem an Stellen, wo der Nutzer es sehen kann (Zeitanzeigen, Zeitstempel in Dateinamen etc.)
    • Vorteil: sofort menschenlesbar
    • Nachteil: muss für Eindeutigkeit immer mit Zeitzoneninformation verknüpft sein; Gültigkeit von zukünftigen Zeitangaben evtl. durch nicht vorhergesehene Zeitzonenänderungen beeinträchtigt
    • Nachteil: textuelle Darstellung je nach Kulturkreis uneindeutig (z.B. "4/7/2021" kann entweder für den 4. Juli oder den 7. April stehen)
  • Option 2: eine einzelne Zahl, die die vergangene Zeit in einer bestimmten Einheit (z.B. Sekunden oder Tage) seit einem Startzeitpunkt (der Epoche) angibt

    • z.B. Unix: Sekunden seit 1. Januar 1970 00:00:00 Uhr UTC (bzw. 01:00:00 Uhr deutscher Zeit)
    • z.B. julianisches Datum: Tage seit 1. Januar 4713 v.u.Z.
    • z.B. Excel, LibreOffice Calc, etc.: Tage seit 1. Januar 1900, mit Nachkommastellen für Zeitpunkte innerhalb eines Tages
  • Probleme durch Überlauf in Datumsfeldern

    • Y2K-Problem: Überlauf in der Jahreszahl, die damals zweistellig angegeben war (z.B. "76" für 1976)
    • Y2038-Problem: Überlauf in einem 32-Bit-Unix-Zeitstempel (am Dienstag, dem 19. Januar 2038 um 04:14:07 Uhr deutscher Zeit)
    • GPS-Wochen-Rollover: Überlauf in der Wochenzahl des Zeitstempel-Formats von GPS; erstmals 1999, zuletzt 2019, nächstes Mal 2038
  • Probleme durch astronomische/politische Fakten

    • Berechnungen wie "10 Tage dazuaddieren" mühselig aufgrund Kalenderregeln (Monatswechsel, Schalttage etc.)
      • Beispiel: in einer Terminserie wie "täglich um 15 Uhr" hat wegen Sommerzeitwechsel nicht jeder Termin genau 24 Stunden Abstand zueinander
      • Beispiel: Sommerzeitumstellung bei der Eisenbahn (diesen Abschnitt können wir im Prinzip direkt vorlesen)
    • Schaltsekunden lassen UTC springen und erzeugen unerwartete Zeitzustände wie "23:59:60"
    • Zeitzonendefinitionen folgen politischen Entscheidungen
      • z.B. Deutschland besteht in tzdata aus zwei Zeitzonen
      • z.B. 2015 Chaos in der Türkei durch eine Änderung der Sommerzeitregel mit zu wenig Vorlauf
  • Probleme durch technische Einflüsse

    • Hardware-Uhren sind nicht hinreichend genau und driften mit der Zeit: in verteilten Systemen mögliche Verwirrung über die Reihenfolge von Aktionen
    • Zeitsynchronisation mittels NTP (Network Time Protocol): im Moment der Richtigstellung der Uhr mögliche Verwirrung durch einen kleinen Sprung rückwärts in der Zeit
    • Suspend/Standby: im Moment des Wiederanschaltens mögliche Verwirrung durch einen drastischen Sprung vorwärts in der Zeit
    • monotonische Uhren: zählen die Zeit, die der Computer seit Systemstart gelaufen sind (z.B. mittels TSC; damit zuverlässige Messung von Laufzeitspannen etc.
  • positiver Ausblick: Es könnte noch viel schlimmer sein!

    • gregorianischer Kalender hat sich weltweit für den Geschäftsverkehr durchgesetzt
    • Beispiel für einen alternativen Kalender: Japanische Zeitrechnung
  • kryptografisch abgesicherte Zeitstempel: RFC Podcast #15 Crypto for the Masses

  continue reading

69 Episoden

Alle Folgen

×
 
Loading …

Willkommen auf Player FM!

Player FM scannt gerade das Web nach Podcasts mit hoher Qualität, die du genießen kannst. Es ist die beste Podcast-App und funktioniert auf Android, iPhone und im Web. Melde dich an, um Abos geräteübergreifend zu synchronisieren.

 

Kurzanleitung

Hören Sie sich diese Show an, während Sie die Gegend erkunden
Abspielen