1. Foren
  2. Kommentare
  3. Wirtschaft
  4. Alle Kommentare zum Artikel
  5. › Neue Kaiserära in Japan: Das Jahr-1…
  6. Thema

Darstellung vs. Speicherung?

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Re: Darstellung vs. Speicherung?

    Autor: thinksimple 29.04.19 - 12:15

    \pub\bash0r schrieb:
    --------------------------------------------------------------------------------
    > Bauen die ihre System ernsthaft so, dass sie das kurzlebige Jahr
    > speichern?
    > Warum arbeiten die nicht intern mit der "Standard" Zeit (Unix Timestamps)
    > und rechnen für die Anzeige aus, ob das jetzt "Jahr 1" oder "Jahr 31" ist?
    > Dafür reicht doch dann eine einfache Tabelle mit einem Mapping, zu welchem
    > Unix-Timestamp die Epoche übergegangen ist.
    > Ja, sowas zu implementieren ist auch Aufwand. Aber anscheinend ja nun
    > nichts, was Japan überraschen sollte. Es hätte da also nie anders
    > implementiert sein dürfen.
    > Bedarf natürlich Sonderlocken in allen ihren Systemen .... aber halt nur zu
    > Anzeige. Im Worstcase steht dann halt mal irgendwo "2019" .... ups. Bugfix,
    > fertig. Es geht aber nichts verloren oder kaputt.

    Wieso glaubst du das in Japan dieses spezielle "Datum" als Schlüsselfeld genommen wird. Intern wird in Japan nicht mit den Kaiserzeiten gerechnet. Es muss nur auf jeglichem Dokument ausgewiesen sein. Da man vorher nie weiß wann das ist muss dies schnell geschehen. Die Umstellung ist genauso problematisch wie wenn es hier heissen würde " In 2 Wochen ist auf jedem Dokument das juljanische Kalenderdatum mit anzugeben, ansonsten sind sie ungültig". Rechne dir mal das chaos in Europa aus bis alle Dokumente dann überall so umgestellt sind. Das ist das Problem nicht das Datum an sich.

    Alleinfahrende Autos hin oder her,
    aber Backpapierzuschnitte sind schon eine geile Erfindung.

  2. Re: Darstellung vs. Speicherung?

    Autor: Hotohori 29.04.19 - 12:38

    Tja, das kommt dabei raus wenn der Entwickler einer Software sich für intelligenter hält als der spätere Nutzer. XD

  3. Re: Darstellung vs. Speicherung?

    Autor: Eheran 29.04.19 - 13:22

    >sollten wir besser gleich das Dezimalsystem durch ein anderes ersetzen, dessen Basis mehr Teiler hat. 6 oder 12 bieten sich hier an.
    Da das Dezimalsystem für Menschen wohl mit Abstand das effizienteste System ist... ne, lieber dabei bleiben.

    >Bei der 6 wäre sehr schön, dass man mit zwei Händen bis 36 anzeigen kann
    Binär kann man mit 10 Fingern bis 1023 zählen. Macht trotzdem niemand, weils halt unnötig ist.

  4. Re: Darstellung vs. Speicherung?

    Autor: \pub\bash0r 29.04.19 - 13:26

    thinksimple schrieb:
    --------------------------------------------------------------------------------
    > Wieso glaubst du das in Japan dieses spezielle "Datum" als Schlüsselfeld
    > genommen wird. Intern wird in Japan nicht mit den Kaiserzeiten gerechnet.

    Ich zitiere den Artikel: "Man hat Angst vor Bugs und Datenverlust." Das klingt schon anders als "Man hat Angst vor semantisch falschen Dokumenten."

  5. Re: Darstellung vs. Speicherung?

    Autor: lestard 29.04.19 - 13:36

    Muhaha schrieb:
    --------------------------------------------------------------------------------
    > Deswegen ja auch die nicht unbegründete Sorge damals bei Y2K, dass irgend
    > eine alte Software an kritischer Stelle die Arbeit verweigert. Normale
    > menschliche und nicht zu verhindernde Nachlässigkeit.

    Der Unterschied ist, dass Y2K beliebig lange vorher voraussehbar gewesen ist. Man hätte 1963 schon wissen können, dass in 37 Jahren die ersten beiden Stellen in der Jahreszahl wechseln.
    Bei der japanischen Ära funktioniert das ja anders. Normalerweise endet eine Ära mit dem Tod des Kaisers. Diesmal hat der amtierende Kaiser von sich aus abgedankt. Das ist alles relativ kurzfristig möglich.

    Auf der anderen Seite hätte man aus dem Grund natürlich die Systeme so bauen müssen, dass die Ära schnell änderbar ist.

  6. Re: Darstellung vs. Speicherung?

    Autor: FreiGeistler 29.04.19 - 13:41

    Epaminaidos schrieb:
    --------------------------------------------------------------------------------
    > ChriDDel schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Was ich da schon erlebt habe.
    >
    > Ja, es ist sehr deprimierend, wie schlecht das Verständnis für den Umgang
    > mit Datumswerten häufig ist.
    > Erst neulich hatte ich mit einer Anwendung zu tun, die amerikanisch und
    > deutsch mischt: 22/09/2018.
    > Oder eine andere, die ISO-Striche mit amerikanischer Reihenfolge verwendet:
    > 09-22-2018
    > Die Punkt-Schreibweise mit amerikanischer Folge ist in irgendeinem
    > afrikanischen Land mWn sogar Standard: 09.22.2018
    >
    > Es ist einfach zum Heulen.

    Dabei sortiert sich doch YYYY-MM-dd besser :-(

  7. Re: Darstellung vs. Speicherung?

    Autor: mnementh 29.04.19 - 18:15

    Eheran schrieb:
    --------------------------------------------------------------------------------
    > >sollten wir besser gleich das Dezimalsystem durch ein anderes ersetzen,
    > dessen Basis mehr Teiler hat. 6 oder 12 bieten sich hier an.
    > Da das Dezimalsystem für Menschen wohl mit Abstand das effizienteste System
    > ist... ne, lieber dabei bleiben.
    >
    Das Dezimalsystem ist nur dann effektiv, wenn alles andere daran angepasst ist. Beispielsweise die SI-Prefixe, die alle 10er-Potenzen sind. Das ist aber so gewählt worden, weil wir ein System mit der Basis 10 benutzen. Ein System zur Basis 6 und 12 sind sehr wohl ebenfalls gut, wie der Vorposter sagt hat das eine gute Teilbarkeit. Oder wir setzen auf gute Kompatibilität mit Computern, dann haben wir mit binären, oktalen oder hexadezimalen Systemen gute Karten.

    Aber das Dezimalsystem ist für Menschen nicht effektiver als ein anderes. Es erscheint Dir nur so, weil Du damit sozialisiert wurdest und alles darauf basierend gelernt hast.

    > >Bei der 6 wäre sehr schön, dass man mit zwei Händen bis 36 anzeigen kann
    > Binär kann man mit 10 Fingern bis 1023 zählen. Macht trotzdem niemand,
    > weils halt unnötig ist.
    https://www.wissenschaft.de/allgemein/das-binaere-fingersystem/
    Eigentlich wäre das sehr praktisch. Es ist aber alles eine Frage der Gewöhnung. Tatsächlich wird in verschiedenen Ländern schon sehr unterschiedlich mit den Fingern gezählt, obwohl die Unterschiede mit der Verbreitung der arabischen Ziffern (und damit des Dezimalsystems) abgenommen hat.

    "Finger-counting systems in use in many regions of Asia allow the counting to 12 by using a single hand. The thumb acts as a pointer touching the three finger bones of each finger in turn, starting with the outermost bone of the little finger. One hand is used to count numbers up to 12. The other hand is used to display the number of completed base-12s. This continues until twelve dozen is reached, therefore 144 is counted."
    https://en.wikipedia.org/wiki/Finger-counting

    Chinesische Zahlenzeichen mit Finger erreichen 10 mit einer Hand und dabei gibt es regionale Unterschiede:
    https://de.wikipedia.org/wiki/Chinesische_Zahlzeichen#Handzeichen_zum_Ausdruck_chinesischer_Zahlen

    Das koreanische Chisanbop erlaubt mit beiden Händen Zahlen bis 99 auszudrücken:
    https://de.wikipedia.org/wiki/Chisanbop

    Das heißt, Leute benutzen andere Systeme nicht, weil unser aktuelles das Beste wäre, sie benutzen einfach nur dass was sie von Kindheit an gelernt haben ohne es jemals zu hinterfragen.

  8. Re: Darstellung vs. Speicherung?

    Autor: Eheran 29.04.19 - 18:29

    >Das heißt, Leute benutzen andere Systeme nicht, weil unser aktuelles das Beste wäre, sie benutzen einfach nur dass was sie von Kindheit an gelernt haben ohne es jemals zu hinterfragen.
    Warum haben wir dann nicht mehr das römische Zahlsystem?
    Vielleicht, weil ein Level erreicht ist, wo eine Verbesserung zwar noch möglich wäre, der Zugewinn aber in keinem Verhältnis zum Aufwand steht?

  9. Re: Darstellung vs. Speicherung?

    Autor: thinksimple 29.04.19 - 21:36

    \pub\bash0r schrieb:
    --------------------------------------------------------------------------------
    > thinksimple schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Wieso glaubst du das in Japan dieses spezielle "Datum" als Schlüsselfeld
    > > genommen wird. Intern wird in Japan nicht mit den Kaiserzeiten
    > gerechnet.
    >
    > Ich zitiere den Artikel: "Man hat Angst vor Bugs und Datenverlust." Das
    > klingt schon anders als "Man hat Angst vor semantisch falschen Dokumenten."

    Dann bin ich froh, das wir das damals beim Japanprojekt anders gelöst haben.
    Aber man muss in Japan doch immer damit rechnen das sich das Kaiserjahr ändert. Wenn der Kaiser plötzlich stürbt?

    Alleinfahrende Autos hin oder her,
    aber Backpapierzuschnitte sind schon eine geile Erfindung.

  10. Re: Darstellung vs. Speicherung?

    Autor: QDOS 30.04.19 - 20:31

    Bonita.M schrieb:
    --------------------------------------------------------------------------------
    > Der Win32-Timestamp ist noch geiler: die Anzahl der vergangenen
    > 100ns-Schritte seit dem 1.1.1601 , 00:00.

    Anscheinend gibt's dafür von Seiten MS sogar eine offizielle Begründung: https://devblogs.microsoft.com/oldnewthing/20090306-00/?p=18913

  11. Re: Darstellung vs. Speicherung?

    Autor: _mbr 30.04.19 - 22:12

    Eheran schrieb:
    --------------------------------------------------------------------------------
    > >Bei der 6 wäre sehr schön, dass man mit zwei Händen bis 36 anzeigen kann
    > Binär kann man mit 10 Fingern bis 1023 zählen. Macht trotzdem niemand,
    > weils halt unnötig ist.

    zeig mal 891 bzw binär 11011 11011 an :-D
    Danach denkst Du an "645"

  12. Re: Darstellung vs. Speicherung?

    Autor: robinx999 01.05.19 - 15:00

    QDOS schrieb:
    --------------------------------------------------------------------------------
    > Bonita.M schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Der Win32-Timestamp ist noch geiler: die Anzahl der vergangenen
    > > 100ns-Schritte seit dem 1.1.1601 , 00:00.
    >
    > Anscheinend gibt's dafür von Seiten MS sogar eine offizielle Begründung:
    > devblogs.microsoft.com

    Wobei man sagen muss eigentlich ist es fast egal welches System genutzt wird, wobei mich das Microsoft System auch schon mal irritiert hat als ich es mal in der Ereignisanzeige gesehen habe als eine Lange Zahl und man dann erst überlegen muss was das jetzt für ein Datum ist
    Ich meinte Excel Nutzt Zeiten die wenn ich mich nicht irren bei 1900 los gehen. Linux bei 1970.
    Am Ende muss man es wohl akzeptieren dass es unterschiedliche Systeme gibt.
    Aber so führt man sich natürlich unterschiedliche Probleme ein. Von dem bekannten Jahr 2000 Problem. Bis hin zu dem zumindest in der nicht IT Affinen Bevölkerung wenig gekanntem Jahr 2038 Problem (Überlauf Unix Time mit 32 Bit). Bis hin zu Problemen mit Software die der Ansicht sind die Jahreszahl muss immer 4 Stellig sein. Mein Favorit ist noch das Jahr 2262 Problem kennt kaum einer ich habe es mal irgendwann bei meinem Linux System ausprobiert (war irgendwann am 11.4.2262), den Overflow quittiert das System mit praktischer Unbenutzbarkeit und 100% CPU Last auf allen Kernen. Da läuft aktuell auch bei 64 Bit Systemen nämlich die Zeit über die als 64 Bit Zeit gespeichert ist und Nanosekunden Seite der Unix Epoch zählt. Aber vermutlich kann ich sagen das Jahr 2262 Problem werde ich wohl genauso wenig wie das Jahr 10000 Problem erleben. Aber ist schon Lustig wenn bei Linux bei der Diskussion immer wieder erwähnt wird das Jahr 2038 Problem ist durch 64 Bit so weit gelöst das es erst ein Problem in mehren Milliarden Jahren ist.

  13. Re: Darstellung vs. Speicherung?

    Autor: Bonita.M 01.05.19 - 15:05

    > Bis hin zu dem zumindest in der nicht IT Affinen Bevölkerung wenig
    > gekanntem Jahr 2038 Problem (Überlauf Unix Time mit 32 Bit).

    ... wenn bis dahin noch Systeme überleben wo time_t 32-bittig ist.

  14. Re: Darstellung vs. Speicherung?

    Autor: robinx999 01.05.19 - 17:06

    Bonita.M schrieb:
    --------------------------------------------------------------------------------
    > > Bis hin zu dem zumindest in der nicht IT Affinen Bevölkerung wenig
    > > gekanntem Jahr 2038 Problem (Überlauf Unix Time mit 32 Bit).
    >
    > ... wenn bis dahin noch Systeme überleben wo time_t 32-bittig ist.


    Bei Desktop Systemen vermutlich nein.
    Bei Software wo die ein oder andere Variable explizit als 32 Bit definiert ist oder nur 32 Bit in irgendwelchen Datenbank gespeichert werden da geht bestimmt einiges durch und wird übersehen.
    Wenn ich mir jetzt so aber manche Systeme anschaue wo dann noch die 100 Mbit Switches im Schrank sind oder wenn teilweise sogar mal ein 10 Mbit Switch, ja da würde ich vermuten trifft man es noch. Ob da jetzt der ein oder andere Router / Switch Probleme macht müsste man schauen. Arduino bzw. auf den Clonen basierte Systeme dürften auch oft nur 32 Bit haben

    Ich bin übrigens vor ein paar Monaten auf ein Jahr 2038 Problem in der Wildnis gestoßen. Neues Root CA erstellt für OpenVPN und beim importieren in eine PFSense (reines 32 Bit System) viel mir auf das das Root CA dort kein Enddatum mehr anzeigen konnte (dies lag hinter dem Roll Over) ob dies irgendwelche weiteren Probleme verursacht hätte weiß ich nicht, sicherheitshalber wurde ein neues Root CA erstellt, welches knapp vor dem Rollover abläuft

  15. Re: Darstellung vs. Speicherung?

    Autor: Bonita.M 01.05.19 - 17:14

    > Bei Software wo die ein oder andere Variable explizit als 32 Bit definiert
    > ist ...

    Wenn ich time_t nehme, dann ist das automatisch je nach Zielplattform in der Größe die es eben für die jeweilige Plattform hat. Das in einen anderen Typen zu casten, das macht wohl kaum einer. Und selbst die meiesten 32-bittigen Unices dürften einen 64-bittigen time_t haben bzw. das hat man sicher schon vor Äonen angepasst.

    > oder nur 32 Bit in irgendwelchen Datenbank gespeichert werden ...

    In einer Datenbank speichert man keinem time_t, sondern die Datenbank-typischen Angaben DATE, TIME, DATETIME etc.

    > Wenn ich mir jetzt so aber manche Systeme anschaue wo dann noch die 100
    > Mbit Switches im Schrank sind oder wenn teilweise sogar mal ein 10 Mbit
    > Switch, ja da würde ich vermuten trifft man es noch.

    Dürfte selten sein.

    > Arduino bzw. auf den Clonen basierte Systeme dürften auch oft nur 32 Bit haben

    Mit einem System was nur 1kB RAM hat machst Du eh keine Datumsarithmetik.

  16. Re: Darstellung vs. Speicherung?

    Autor: robinx999 01.05.19 - 17:18

    Eheran schrieb:
    --------------------------------------------------------------------------------
    > >Das heißt, Leute benutzen andere Systeme nicht, weil unser aktuelles das
    > Beste wäre, sie benutzen einfach nur dass was sie von Kindheit an gelernt
    > haben ohne es jemals zu hinterfragen.
    > Warum haben wir dann nicht mehr das römische Zahlsystem?
    > Vielleicht, weil ein Level erreicht ist, wo eine Verbesserung zwar noch
    > möglich wäre, der Zugewinn aber in keinem Verhältnis zum Aufwand steht?

    Zumindest bei Zeigen von Zahlen mit Fingern ist unser System in Deutschland den anderen Unterlegen, aber dies macht man ja fast nur in lauten Umgebungen.
    Die Römischen Zahlen hatten viele Nachteile man könnte mit Ihnen nicht vernünftig rechnen, große Zahlen waren schwer zu erfassen. Computer verwenden aber nicht umsonst das Dezimalsystem.
    Mit dem Hexadezimalsystem gibt es sogar eine "Variante" die eigentlich nicht so schlecht ist es liegt uns aber nicht und die Leute darauf umzustellen dürfte extrem problematisch werden und ja der Nutzen wäre vermutlich nur Minimal.
    Die Dezimalzeit wäre schon nützlicher, aber auch die hat sich nicht durchgesetzt, wobei hier Rechnungen viel Einfacher wären, man müsste auch nicht fragen ob jemand wenn er 9Uhr sagt abends oder morgens meint
    https://de.wikipedia.org/wiki/Dezimalzeit

  17. Re: Darstellung vs. Speicherung?

    Autor: robinx999 01.05.19 - 17:28

    Bonita.M schrieb:
    --------------------------------------------------------------------------------
    > > Bei Software wo die ein oder andere Variable explizit als 32 Bit
    > definiert
    > > ist ...
    >
    > Wenn ich time_t nehme, dann ist das automatisch je nach Zielplattform in
    > der Größe die es eben für die jeweilige Plattform hat. Das in einen anderen
    > Typen zu casten, das macht wohl kaum einer. Und selbst die meiesten
    > 32-bittigen Unices dürften einen 64-bittigen time_t haben bzw. das hat man
    > sicher schon vor Äonen angepasst.
    >
    Leute machen alles mögliche in Programmen da wäre ich vorsichtig, dass zu verallgemeinern.
    > > oder nur 32 Bit in irgendwelchen Datenbank gespeichert werden ...
    >
    > In einer Datenbank speichert man keinem time_t, sondern die
    > Datenbank-typischen Angaben DATE, TIME, DATETIME etc.
    >
    Was man da speichert ist halt eine Frage klar wäre das genannte richtig, aber man kann auf alles mögliche Treffen.
    > > Wenn ich mir jetzt so aber manche Systeme anschaue wo dann noch die 100
    > > Mbit Switches im Schrank sind oder wenn teilweise sogar mal ein 10 Mbit
    > > Switch, ja da würde ich vermuten trifft man es noch.
    >
    > Dürfte selten sein.
    >
    > > Arduino bzw. auf den Clonen basierte Systeme dürften auch oft nur 32 Bit
    > haben
    >
    > Mit einem System was nur 1kB RAM hat machst Du eh keine Datumsarithmetik.

    Also ich habe zumindest auch Clone erlaubt, und so ein ESP32 hat häufig 4 MB Flash + 512kb RAM. Damit geht schon etwas, WLAN haben die Geräte auch häufig. Die können sich über WLAN schon das Datum holen und es evtl. auf einem Display anzeigen und dann z.B.: von anderen Quellen Dinge auf einem Display anzeigen, das Wetter der nächsten 3 Tage (kann man sich auf dem Internet laden), wobei hier natürlich die Chance hoch ist das Dienste wie "openweathermap" entweder nicht mehr existieren oder ihre API angepasst haben, aber etwas mit dem Datum rechnet man da schon. Eigentlich plane ich immer noch, aber ich finde keine Zeit, mir so ein Gerät mit E-paper zu basteln, welches ein mal pro Stunde meinen Kalender (CalDAV) abruft, und mir einen Kalender rendert mit den aktuellen Terminen die ich habe, da wäre also auch etwas Datumsarithmetik dabei.

    EDIT:
    nicht zu vergessen Dinge wie die Sonoff Smart Home Produkte (eigentlich eine grausame App), aber mit alternativer Firmware kann man damit auch gutes machen und am ende ist es auch nur ein ESP8266 der ein Relai schaltet um Strom ein oder aus zu schalten. Aber für Zeitpläne, wann geschaltet werden soll ist ein funktionierendes Datum wohl auch nicht schlecht.

    Nebenbei wäre es interessant zu erfahren wie die ganzen anderen Smart Home Systeme auf das Jahr 2038 Problem vorbereitet sind



    1 mal bearbeitet, zuletzt am 01.05.19 17:36 durch robinx999.

  18. Re: Darstellung vs. Speicherung?

    Autor: Bonita.M 01.05.19 - 17:35

    >> Wenn ich time_t nehme, dann ist das automatisch je nach Zielplattform
    >> in der Größe die es eben für die jeweilige Plattform hat. Das in einen
    >> anderen Typen zu casten, das macht wohl kaum einer. Und selbst die
    >> meiesten 32-bittigen Unices dürften einen 64-bittigen time_t haben
    >> bzw. das hat man sicher schon vor Äonen angepasst.

    > Leute machen alles mögliche in Programmen da wäre ich vorsichtig,
    > dass zu verallgemeinern.

    Ist halt sehr unwahrscheinlich. Und es ist sowieso unwahrscheinlich, dass jemand für jeden Typ der Datumsspeicherung time_t verwendet. Außerhalb von Filesystemen hat das nämlich kaum Bedeutung.

    >> In einer Datenbank speichert man keinem time_t, sondern die
    >> Datenbank-typischen Angaben DATE, TIME, DATETIME etc.

    > Was man da speichert ist halt eine Frage klar wäre das genannte richtig,
    > aber man kann auf alles mögliche Treffen.

    Die Datentypen der Datenbank sind die naheliegendsten und nur mit denen lässt sich mit SQL-typischen Zeitfunktionen rechnen; insofern kommt da kaum jemand auf die Idee, time_t in den Kontext zu bringen.

    >>> Arduino bzw. auf den Clonen basierte Systeme dürften auch oft nur 32
    >>> Bit haben

    >> Mit einem System was nur 1kB RAM hat machst Du eh keine
    >> Datumsarithmetik.

    > Also ich habe zumindest auch Clone erlaubt, und so ein ESP32 hat häufig 4
    > MB Flash + 512kb RAM.

    Das sind keine Arduinos.
    Der Arduino hat schon logisch einen sehr viel kleineren Adresraum da sowas was Du hier beschreibst nichtmal theoretisch geht.

  19. Re: Darstellung vs. Speicherung?

    Autor: robinx999 01.05.19 - 18:04

    Bonita.M schrieb:
    --------------------------------------------------------------------------------
    > >> Wenn ich time_t nehme, dann ist das automatisch je nach Zielplattform
    > >> in der Größe die es eben für die jeweilige Plattform hat. Das in einen
    > >> anderen Typen zu casten, das macht wohl kaum einer. Und selbst die
    > >> meiesten 32-bittigen Unices dürften einen 64-bittigen time_t haben
    > >> bzw. das hat man sicher schon vor Äonen angepasst.
    >
    > > Leute machen alles mögliche in Programmen da wäre ich vorsichtig,
    > > dass zu verallgemeinern.
    >
    > Ist halt sehr unwahrscheinlich. Und es ist sowieso unwahrscheinlich, dass
    > jemand für jeden Typ der Datumsspeicherung time_t verwendet. Außerhalb von
    > Filesystemen hat das nämlich kaum Bedeutung.
    >
    > >> In einer Datenbank speichert man keinem time_t, sondern die
    > >> Datenbank-typischen Angaben DATE, TIME, DATETIME etc.
    >
    > > Was man da speichert ist halt eine Frage klar wäre das genannte richtig,
    > > aber man kann auf alles mögliche Treffen.
    >
    > Die Datentypen der Datenbank sind die naheliegendsten und nur mit denen
    > lässt sich mit SQL-typischen Zeitfunktionen rechnen; insofern kommt da kaum
    > jemand auf die Idee, time_t in den Kontext zu bringen.
    >
    So unrealistisch ist dies gar nicht.
    Hier mal ein Beispiel aus der Datenbank von Nextcloud von meinem kleinen Heimserver, sind jetzt eh nur die Beispieldateien:
    mysql> mysql> select * from oc_filecache LIMIT 10;
    +--------+---------+------------------------------+----------------------------------+--------+-----------------+----------+----------+---------+------------+---------------+-----------+------------------+----------------------------------+-------------+----------+
    | fileid | storage | path | path_hash | parent | name | mimetype | mimepart | size | mtime | storage_mtime | encrypted | unencrypted_size | etag | permissions | checksum |
    +--------+---------+------------------------------+----------------------------------+--------+-----------------+----------+----------+---------+------------+---------------+-----------+------------------+----------------------------------+-------------+----------+
    | 1 | 1 | | d41d8cd98f00b204e9800998ecf8427e | -1 | | 2 | 1 | 2438507 | 1525970330 | 1488580127 | 0 | 0 | 5af4759a3a855 | 23 | |
    | 2 | 1 | files | 45b963397aa40d4a0063e0d85e4fe7a1 | 1 | files | 2 | 1 | 2438507 | 1520764490 | 1520764489 | 0 | 0 | 5aa5064a5e6f1 | 31 | |
    | 3 | 1 | files/Documents | 0ad78ba05b6961d92f7970b2b3922eca | 2 | Documents | 2 | 1 | 78496 | 1487878374 | 1487878373 | 0 | 0 | 58af38e6359d6 | 31 | |
    | 4 | 1 | files/Documents/About.odt | b2ee7d56df9f34a0195d4b611376e885 | 3 | About.odt | 4 | 3 | 77422 | 1487878373 | 1487878373 | 0 | 0 | 9bfca400f76b9807b5f8db55510dfd8a | 27 | |
    | 5 | 3 | | d41d8cd98f00b204e9800998ecf8427e | -1 | | 2 | 1 | 6349266 | 1556645712 | 1545647555 | 0 | 0 | 5cc887511caf3 | 23 | |
    | 8 | 1 | files/Documents/About.txt | 9da7b739e7a65d74793b2881da521169 | 3 | About.txt | 6 | 5 | 1074 | 1487878374 | 1487878374 | 0 | 0 | 4eecf57123bb28c571b3cb44ee9d60e1 | 27 | |
    | 9 | 1 | files/Photos | d01bb67e7b71dd49fd06bad922f521c9 | 2 | Photos | 2 | 1 | 2360011 | 1487878375 | 1487878375 | 0 | 0 | 58af38e7bd32e | 31 | |
    | 10 | 1 | files/Photos/Coast.jpg | a6fe87299d78b207e9b7aba0f0cb8a0a | 9 | Coast.jpg | 8 | 7 | 819766 | 1487878375 | 1487878375 | 0 | 0 | eebfcc4252527ba30e2d15e0c73d291f | 27 | |
    | 11 | 1 | files/Photos/Hummingbird.jpg | e077463269c404ae0f6f8ea7f2d7a326 | 9 | Hummingbird.jpg | 8 | 7 | 585219 | 1487878375 | 1487878375 | 0 | 0 | 4cb51006e279f9edadc2d3309b51c9d3 | 27 | |
    | 12 | 1 | files/Photos/Nut.jpg | aa8daeb975e1d39412954fd5cd41adb4 | 9 | Nut.jpg | 8 | 7 | 955026 | 1487878376 | 1487878376 | 0 | 0 | 8341a54b106f4a19e93df166df6a4e19 | 27 | |
    +--------+---------+------------------------------+----------------------------------+--------+-----------------+----------+----------+---------+------------+---------------+-----------+------------------+----------------------------------+-------------+----------+
    10 rows in set (0,00 sec)

    Ich hoffe man kann es lesen, folgendes gibt es auch noch
    mysql> describe oc_filecache;
    +------------------+---------------+------+-----+---------+----------------+
    | Field | Type | Null | Key | Default | Extra |
    +------------------+---------------+------+-----+---------+----------------+
    | fileid | int(11) | NO | PRI | NULL | auto_increment |
    | storage | int(11) | NO | MUL | 0 | |
    | path | varchar(4000) | YES | | NULL | |
    | path_hash | varchar(32) | NO | | | |
    | parent | int(11) | NO | MUL | 0 | |
    | name | varchar(250) | YES | | NULL | |
    | mimetype | int(11) | NO | | 0 | |
    | mimepart | int(11) | NO | | 0 | |
    | size | bigint(20) | NO | | 0 | |
    | mtime | int(11) | NO | | 0 | |
    | storage_mtime | int(11) | NO | | 0 | |
    | encrypted | int(11) | NO | | 0 | |
    | unencrypted_size | bigint(20) | NO | | 0 | |
    | etag | varchar(40) | YES | | NULL | |
    | permissions | int(11) | YES | | 0 | |
    | checksum | varchar(255) | YES | | NULL | |
    +------------------+---------------+------+-----+---------+----------------+
    16 rows in set (0,00 sec)

    mtime uns storage_mtime sind also int(11)
    Wenn ich das richtig sehe haben wir hier also ein Jahr 2038 Problem
    https://www.virendrachandak.com/techtalk/mysql-int11-what-does-it-means/
    Es gibt hier wohl den ein oder anderen Foren Eintrag das man mit einem passenden Nextcloud Befehl diese spalten zu Bigint konvertieren kann, aber hier ist schon eine Software die ein Problem haben kann. Aber klar wenn es bei relativ bekannten aktuellen Projekten wie Own bzw. Nextcloud gemacht wird warum sollen andere nicht auch solche Daten speichern.

    > >>> Arduino bzw. auf den Clonen basierte Systeme dürften auch oft nur 32
    > >>> Bit haben
    >
    > >> Mit einem System was nur 1kB RAM hat machst Du eh keine
    > >> Datumsarithmetik.
    >
    > > Also ich habe zumindest auch Clone erlaubt, und so ein ESP32 hat häufig
    > 4
    > > MB Flash + 512kb RAM.
    >
    > Das sind keine Arduinos.
    > Der Arduino hat schon logisch einen sehr viel kleineren Adresraum da sowas
    > was Du hier beschreibst nichtmal theoretisch geht.

    Naja ich dachte im wesentlichen an solche Projekte
    https://github.com/doctormord/ESP8266_EPD_Weather_Google_Calendar
    Da das Ding sogar
    https://github.com/esp8266/Arduino
    Arduino core for ESP8266 WiFi chip heißt würde ich das noch mit zu den Clonen zählen.

    und nicht zu vergessen aus meinem vorherigen Edit wo ich wohl etwas zu langsam war

    nicht zu vergessen Dinge wie die Sonoff Smart Home Produkte (eigentlich eine grausame App), aber mit alternativer Firmware kann man damit auch gutes machen und am ende ist es auch nur ein ESP8266 der ein Relai schaltet um Strom ein oder aus zu schalten. Aber für Zeitpläne, wann geschaltet werden soll ist ein funktionierendes Datum wohl auch nicht schlecht.

    Nebenbei wäre es interessant zu erfahren wie die ganzen anderen Smart Home Systeme auf das Jahr 2038 Problem vorbereitet sind

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Embedded Softwareentwickler (m/w/d)
    Hays AG, Hamburg
  2. SAP-Anwendungsbetreuer SD/MM
    Hays AG, Karlsruhe
  3. IT - Systemadministrator (m/w/d)
    Winterhalder Selbstklebetechnik GmbH, Heitersheim
  4. VBA-Entwickler und IDV-Koordinator (m/w/d)
    L-Bank, Karlsruhe

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. mit 89€ neuer Bestpreis auf Geizhals
  2. 69,99€ (Release 07.10.)
  3. 589€ (Bestpreis)
  4. (u. a. Gears 5 für 9,99€, Forza Horizon 4 für 29,99€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Dragonbox-Pyra-Macher im Interview: Die Linux-Spielekonsole aus Deutschland
Dragonbox-Pyra-Macher im Interview
Die Linux-Spielekonsole aus Deutschland

Mit viel Verspätung ist die Dragonbox Pyra erschienen. Entwickler Michael Mrozek musste ganz schön kämpfen, damit es überhaupt dazu kam. Wir haben ihn in Ingolstadt zum Gespräch getroffen.
Ein Interview von Martin Wolf


    Förderung von E-Autos und Hybriden: Wie viel Geld bekomme ich für den Kauf eines Elektroautos?
    Förderung von E-Autos und Hybriden
    Wie viel Geld bekomme ich für den Kauf eines Elektroautos?

    Ein E-Auto ist in der Anschaffung teurer als ein konventionelles. Käufer können aber Zuschüsse bekommen. Wir beantworten zehn wichtige Fragen dazu.
    Von Werner Pluta

    1. Lordstown Chefs von Elektro-Truck-Firma nach Betrug zurückgetreten
    2. Elektromobilität Rennserie E1 zeigt elektrisches Schnellboot
    3. Elektromobilität Green-Vision gibt Akkus aus Elektroautos neuen Zweck

    Kia EV6: Überzeugender Angriff auf die elektrische Luxusklasse
    Kia EV6
    Überzeugender Angriff auf die elektrische Luxusklasse

    Mit einer 800-Volt-Architektur und Ladeleistungen von bis zu 250 kW fordert Kias neues Elektroauto EV6 nicht nur Tesla heraus.
    Ein Hands-on von Franz W. Rother

    1. Elektroauto Der EV6 von Kia kommt im Herbst auf den Markt
    2. Elektroauto Kia zeigt unverhüllte Fotos des EV6
    3. Elektroauto Kia veröffentlicht erste Bilder des EV6