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

Darstellung vs. Speicherung?

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Darstellung vs. Speicherung?

    Autor: \pub\bash0r 29.04.19 - 09:29

    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.

  2. Re: Darstellung vs. Speicherung?

    Autor: nolonar 29.04.19 - 09:36

    Das gleiche frage ich mich auch.
    Es gibt keinen Grund, warum Japan nicht 1999 speichern und per einfachem Mapping "Heisei 21" anzeigen kann. Die Japaner benutzen sogar zum Teil beide Systeme parallel.

    Genauso können auch wir 1999 speichern und einfach nur "99" anzeigen. Verglichen mit "Bugs und Datenverlust" ist die Implementierung eines solchen Mappings kein grosser Aufwand.

  3. Re: Darstellung vs. Speicherung?

    Autor: Muhaha 29.04.19 - 10:01

    nolonar schrieb:
    --------------------------------------------------------------------------------
    > Das gleiche frage ich mich auch.
    > Es gibt keinen Grund, warum Japan nicht 1999 speichern und per einfachem
    > Mapping "Heisei 21" anzeigen kann. Die Japaner benutzen sogar zum Teil
    > beide Systeme parallel.
    >
    > Genauso können auch wir 1999 speichern und einfach nur "99" anzeigen.
    > Verglichen mit "Bugs und Datenverlust" ist die Implementierung eines
    > solchen Mappings kein grosser Aufwand.

    Du wisst doch, wie das ist. Es wird nicht gemacht, weil die Zeit drängt, weil es nicht im Projektplan vorgesehen war, weil der zuständige Entwickler ausfällt und niemand mehr daran denkt ... und dann haben wir eine Software, die GENAU HIER ein Problem hat, weil aus vorher besagten Gründen niemand eine vernünftige Konvertierung implementiert hat.

    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.

  4. Re: Darstellung vs. Speicherung?

    Autor: elgooG 29.04.19 - 10:14

    Ganz richtig erkannt! Die Realität ist oft anders und wenn es sich seit 1989 durchgesetzt hat die Zeit auf japanische Weise zu speichern und noch dazu ein typisch japanisch uneinsichtiges Management hat, kann es vorkommen, dass Systeme ewig nicht umgestellt werden.

    Obwohl es natürlich auch vorkommen kann, dass selbst wenn man Unix-Timestamps verwendet, unzählige Reports für Formulare und Druckerzeugnisse umgestellt werden müssen, weil diese direkt eingegeben wurden, anstatt Daten aus einer Datenbank zu holen. Auch hier können viele Kosten entstehen.

    ...und das alles weil irgend ein überwichtiger Symbolträger ohne Funktion meint, dass eine neue Ära anzufangen hat. Denn mal ehrlich eigentlich hätte man auch hier die Möglichkeit gehabt auf den Wechsel zu verzichten, oder gleich das internationale japanische Format YYYY.MM.DD zu verwenden. Aber sich von Traditionen zu trennen, darf man von (älteren) Japanern leider nicht verlangen.

    Kann Spuren von persönlichen Meinungen, Sarkasmus und Erdnüssen enthalten. Ausdrucke nicht für den Verzehr geeignet. Ungelesen mindestens haltbar bis: siehe Rückseite

  5. Re: Darstellung vs. Speicherung?

    Autor: Bonita.M 29.04.19 - 10:17

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

  6. Re: Darstellung vs. Speicherung?

    Autor: ChriDDel 29.04.19 - 10:29

    So einfach ist das nicht.
    Der Unix Timestamp ist nicht die ultimative Zeitrechnung.
    Dein Linux mit Oracle DB speichert Integer ab. Du machst einen Export mit Integer.
    Das System, welches deinen Export einließt, nutzt MS SQL. BINGO. Andere Zeitrechnung. Also mapping. Du weißt auch nicht, wie der Integer gemeint ist wenn du nicht weißt, das der Export aus Linux kam.
    Also schreiben wir das Datum als Integer aus. 20190429. Funktioniert gut. Bis du auf einen US Amerikaner triffst. YYYYMMDD? Kenn ich nicht - YYYYDDMM kenn ich - oder doch MM/DD/YYYY?
    Ausgeschrieben als UTC? Das macht keine Sau.
    Datumsangaben die Systemübergreifend sind sind immer ein Problem.
    Was ich da schon erlebt habe. Technisher Batchuser hat andere NLS Parameter eingestellt als der "normale" User etc.

  7. Re: Darstellung vs. Speicherung?

    Autor: nolonar 29.04.19 - 10:30

    Muhaha schrieb:
    --------------------------------------------------------------------------------
    > Du wisst doch, wie das ist. Es wird nicht gemacht, weil die Zeit drängt, [...]

    Ich meine, es ist viel schneller und einfacher, einen DateTime zu nutzen, als mehrere Integer. Alle wichtigen Funktionen sind auch schon im Voraus implementiert.

    Meiner Meinung nach ist das keine Frage der Zeit, sondern der Kompetenz des Entwicklers.

  8. Re: Darstellung vs. Speicherung?

    Autor: nolonar 29.04.19 - 10:36

    ChriDDel schrieb:
    --------------------------------------------------------------------------------
    > Also schreiben wir das Datum als Integer aus. 20190429. Funktioniert gut.
    > Bis du auf einen US Amerikaner triffst. YYYYMMDD? Kenn ich nicht - YYYYDDMM
    > kenn ich - oder doch MM/DD/YYYY?

    ISO 8601: yyyy-MM-ddTHH:mm:ss+HH:mm
    [xkcd.com]

    Beispiel: 2019-04-29T08:35:00+02:00

  9. Re: Darstellung vs. Speicherung?

    Autor: Muhaha 29.04.19 - 10:43

    nolonar schrieb:
    --------------------------------------------------------------------------------

    > Meiner Meinung nach ist das keine Frage der Zeit, sondern der Kompetenz des
    > Entwicklers.

    Du, ich wollte nur höflich sein :) ... klar, es gibt gute und schlechte Entwickler.

  10. Re: Darstellung vs. Speicherung?

    Autor: ThorstenMUC 29.04.19 - 11:19

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

    Du meinst den Unix-Timestamp, der 2038 überlaufen wird? ;-)

    Egal wie du speicherst... die wenigsten Zählmethoden wurden für die Ewigkeit spezifiert. Damals war Speicher knapp und irgendwie hat niemand damit gerechnet, dass die Heute erstellte Software evtl. noch in 50 Jahren irgendwo läuft...

  11. Re: Darstellung vs. Speicherung?

    Autor: Bonita.M 29.04.19 - 11:25

    > Du meinst den Unix-Timestamp, der 2038 überlaufen wird? ;-)

    time_t ist schon länger 64-bittig bzw. nur noch auf Altsystemen 32-bittig.

  12. Re: Darstellung vs. Speicherung?

    Autor: tomatentee 29.04.19 - 11:26

    Ich hätte da leise Zweifel, ob es das ‘89 schon gab ;-)

  13. Re: Darstellung vs. Speicherung?

    Autor: ThorstenMUC 29.04.19 - 11:30

    Bonita.M schrieb:
    --------------------------------------------------------------------------------
    > > Du meinst den Unix-Timestamp, der 2038 überlaufen wird? ;-)
    >
    > time_t ist schon länger 64-bittig bzw. nur noch auf Altsystemen 32-bittig.

    Bei neuen Systemen erwartet auch niemand diese Art Probleme... es geht ja nur um Altsysteme.

  14. Re: Darstellung vs. Speicherung?

    Autor: Bonita.M 29.04.19 - 11:32

    > Bei neuen Systemen erwartet auch niemand diese Art Probleme... es geht ja
    > nur um Altsysteme.

    Die müssen aber sehr alt sein.
    Aber ansonsten ist time_t kein gebräuchlicher Datentyp zum Speichern von Datumsangaben - außerhalb von Filesystemen.

  15. Re: Darstellung vs. Speicherung?

    Autor: mnementh 29.04.19 - 11:37

    elgooG schrieb:
    --------------------------------------------------------------------------------
    > ...und das alles weil irgend ein überwichtiger Symbolträger ohne Funktion
    > meint, dass eine neue Ära anzufangen hat.
    Unsere Zeitrechnung hängt an der Geburt irgendeines Scharlatans und Sektenführers, der seinerzeit unheimlich populär war. Ich sehe nicht den signifikanten Vorteil.

    > Denn mal ehrlich eigentlich hätte
    > man auch hier die Möglichkeit gehabt auf den Wechsel zu verzichten, oder
    > gleich das internationale japanische Format YYYY.MM.DD zu verwenden. Aber
    > sich von Traditionen zu trennen, darf man von (älteren) Japanern leider
    > nicht verlangen.
    Willst Du Dich von Deiner Tradition trennen und auf ein neues System wie Sternzeit umstellen? Wieso sollten beispielsweise in Zukunft Menschen die auf dem Mond, Mars oder in weltraumstationen leben sich einem Zeitsystem beugen, dass von der Tageslänge auf einem zufälligen Planeten im Solarsystem abhängt? Welche noch nicht einmal fest ist, die Rotationsdauer der Erde sowohl um sich selbst als auch um die Sonne variiert. Unser Zeitsystem hat viele Mängel, aber wir halten aus Tradition daran fest. Und mal im Detail welche Zeit bevorzugts Du denn persönlich: UT0, UT1, UT2, UTC oder TAI?

    https://de.wikipedia.org/wiki/Universal_Time
    https://de.wikipedia.org/wiki/Koordinierte_Weltzeit
    https://de.wikipedia.org/wiki/Internationale_Atomzeit

  16. Re: Darstellung vs. Speicherung?

    Autor: Epaminaidos 29.04.19 - 11:45

    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.

  17. Re: Darstellung vs. Speicherung?

    Autor: Urbautz 29.04.19 - 11:47

    Und warum ein Tag jetzt 24 stunden haben muss ist ja auch nur historisch begründet (Ägypter glaube ich?)

    Besser wäre es hier echt, auf unser sonst übliches 10er-System zu gehen.

    Wobei ich immer noch unterschiede sehe zwischen "Zeit speichern" und "Zeit anzeigen". Aber ich habe auch schon Systeme gesehen da haben wir jetzt das jahr 119, weil man das Y2K-Problem gelöst hat indem man EINE Stelle angehängt hat.

  18. Re: Darstellung vs. Speicherung?

    Autor: Epaminaidos 29.04.19 - 11:52

    Urbautz schrieb:
    --------------------------------------------------------------------------------
    > Und warum ein Tag jetzt 24 stunden haben muss ist ja auch nur historisch
    > begründet (Ägypter glaube ich?)
    >
    > Besser wäre es hier echt, auf unser sonst übliches 10er-System zu gehen.

    Wenn wir schon so grundlegend rangehen, sollten wir besser gleich das Dezimalsystem durch ein anderes ersetzen, dessen Basis mehr Teiler hat. 6 oder 12 bieten sich hier an.
    Bei der 6 wäre sehr schön, dass man mit zwei Händen bis 36 anzeigen kann (Linke Hand die 10er (bzw. 6er), rechte Hand die Einer).

    Wir werden aber wohl weder dies, noch die Umstellung des Tages erleben.

  19. Re: Darstellung vs. Speicherung?

    Autor: ChriDDel 29.04.19 - 11:52

    Guter erfarungen habe ich mit YYYYMMDD ohne Iso Striche.
    Denn das kann als Number/integer auch in der Größe verglichen werden.
    20190501>20190429 etc.
    Aber man muss sich immer erst einigen.
    Und selbst wenn das alles abgestimmt ist macht einer ein CSV im Excel auf und drückt auf speichern. Schon hat Excel alle Formate zerstört. Sogar in Feldern die kein Datum sein sollen.

    3.1 - ist bestimmt "03. Jan". NEIN ExceL! Ist es nicht.
    Es war CPU Auslastung Prozent is US Decimal aus dem SQL Server. :-(

  20. Re: Darstellung vs. Speicherung?

    Autor: nolonar 29.04.19 - 12:11

    tomatentee schrieb:
    --------------------------------------------------------------------------------
    > Ich hätte da leise Zweifel, ob es das ‘89 schon gab ;-)

    Das stimmt, aber das ist inzwischen 30 Jahre her.
    UNIX time gibt es schon seit den 70er Jahren, und das Y2K Problem wurde schon 86 in Büchern thematisiert.

    Im Gegensatz zum Y2K, gegen den wir vorausplanen konnten, können die Japaner das Ende der Kaiserzeit nie 100% voraussagen: Wenn der Kaiser plötzlich stirbt, muss eine neue Zeitrechnung her.

    Es ist also schon höchst merkwürdig wenn die Japaner, die schon 89 mit dem Problem konfrontiert waren, immer noch Probleme haben, wenn das Jahr zurückgedreht werden muss.

    Bugs wird man wohl nicht wirklich vermeiden können, aber wenn mein PC "Heisei 32" statt "Reiwa 2" anzeigt, ist das unendlich besser, als wenn ich deswegen Datenverlust erleide.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. OZV GmbH & Co. KG, Würselen
  2. SEG Automotive Germany GmbH, Stuttgart
  3. SIZ GmbH, Bonn
  4. Stadtwerke München GmbH, München

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote


Haben wir etwas übersehen?

E-Mail an news@golem.de


Energiewende: Norddeutschland wird H
Energiewende
Norddeutschland wird H

Japan macht es vor, die norddeutschen Bundesländer ziehen nach: Im November haben sie den Aufbau einer Wasserstoffwirtschaft beschlossen. Die Voraussetzungen dafür sind gegeben. Aber das Ende der Förderung von Windkraft kann das Projekt gefährden.
Eine Analyse von Werner Pluta

  1. Energiewende Brandenburg bekommt ein Wasserstoff-Speicherkraftwerk
  2. Energiewende Dänemark plant künstliche Insel für Wasserstofferzeugung
  3. Energiewende Nordländer bauen gemeinsame Wasserstoffwirtschaft auf

Schräges von der CES 2020: Die Connected-Kartoffel
Schräges von der CES 2020
Die Connected-Kartoffel

CES 2020 Wer geglaubt hat, er hätte schon alles gesehen, musste sich auch dieses Jahr auf der CES eines Besseren belehren lassen. Wir haben uns die Zukunft der Kartoffel angesehen: Sie ist smart.
Ein Bericht von Martin Wolf

  1. Smart Lock Netatmo und Yale zeigen smarte Türschlösser
  2. Eracing Simulator im Hands on Razers Renn-Simulator bringt uns zum Schwitzen
  3. Zu lange Ladezeiten Ford setzt auf Hybridantrieb bei autonomen Taxis

Europäische Netzpolitik: Die Rückkehr des Axel Voss
Europäische Netzpolitik
Die Rückkehr des Axel Voss

Elektronische Beweismittel, Nutzertracking, Terrorinhalte: In der EU stehen in diesem Jahr wichtige netzpolitische Entscheidungen an. Auch Axel Voss will wieder mitmischen. Und wird Ursula von der Leyen mit dem "Digitale-Dienste-Gesetz" wieder zu "Zensursula"?
Eine Analyse von Friedhelm Greis

  1. Mitgliederentscheid Netzpolitikerin Esken wird SPD-Chefin
  2. Nach schwerer Krankheit FDP-Netzpolitiker Jimmy Schulz gestorben

  1. Quartalszahlen: Intel macht Rekord bei Umsatz und Gewinn
    Quartalszahlen
    Intel macht Rekord bei Umsatz und Gewinn

    Allen Lieferschwierigkeiten und Sicherheitslücken zum Trotz: Intel setzte im vierten Quartal 2019 über 20 Milliarden US-Dollar bei fast 7 Milliarden US-Dollar Gewinn um, gerade die Xeons waren stark.

  2. Satellit: SD-Abschaltung der ARD kommt erst nächstes Jahr
    Satellit
    SD-Abschaltung der ARD kommt erst nächstes Jahr

    Obwohl kein Geld mehr dafür bewilligt ist, will die ARD die SD-Abschaltung im Jahr 2020 nicht vollziehen. Sie wird wohl auf das zweite Halbjahr 2021 verschoben.

  3. Disney+: Darth Maul kehrt in Star Wars: The Clone Wars zurück
    Disney+
    Darth Maul kehrt in Star Wars: The Clone Wars zurück

    Die siebte und letzte Staffel der Animationsserie Star Wars: The Clone Wars kommt im Februar. Fans können sich auf Mace Windu, Obi Wan Kenobi, Anakin Skywalker und andere Charaktere freuen. Ein Highlight: das Duell zwischen Ahsoka Taano und Darth Maul.


  1. 22:45

  2. 17:52

  3. 17:30

  4. 17:15

  5. 17:00

  6. 16:50

  7. 16:18

  8. 15:00