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. Stadtwerke München GmbH, München
  2. Bezirkskliniken Mittelfranken, Erlangen, Engelthal bei Nürnberg
  3. über duerenhoff GmbH, Würzburg
  4. Deutsche Rentenversicherung Bund, Berlin

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. Star Wars: Der Aufstieg Skywalkers für 28,99€, Die Eiskönigin 2 für 19,99€, Parasite...
  2. (u. a. Transcend 430S 512GB SSD für 68,99€, Transcend 960GB SSD extern für 185,99€, Transcend...
  3. (aktuell u. a. Emtec T700 Lightning > USB-A 1,2m für 8,89€, Emtec T650C Type-C Hub für 36...


Haben wir etwas übersehen?

E-Mail an news@golem.de


Dreams im Test: Bastelwastel im Traumiversum
Dreams im Test
Bastelwastel im Traumiversum

Bereits mit Little Big Planet hat das Entwicklerstudio Media Molecule eine Kombination aus Spiel und Editor produziert, nun geht es mit Dreams noch ein paar Schritte weiter. Mit dem PS4-Titel muss man sich fast schon anstrengen, um nicht schöne Eigenkreationen zu erträumen.
Ein Test von Peter Steinlechner

  1. Ausdiskutiert Sony schließt das Playstation-Forum
  2. Sony Absatz der Playstation 4 geht weiter zurück
  3. PS4-Rücktasten-Ansatzstück im Test Tuning für den Dualshock 4

Generationenübergreifend arbeiten: Bloß nicht streiten
Generationenübergreifend arbeiten
Bloß nicht streiten

Passen Generation Silberlocke und Generation Social Media in ein IT-Team? Ganz klar: ja! Wenn sie ihr Wissen teilen, kommt am Ende sogar Besseres heraus. Entscheidend ist die gleiche Wertschätzung beider Altersgruppen und keine Konflikte in den altersgemischten Teams.
Von Peter Ilg

  1. Frauen in der Technik Von wegen keine Vorbilder!
  2. Arbeit Warum anderswo mehr Frauen IT-Berufe ergreifen
  3. Arbeit Was IT-Recruiting von der Bundesliga lernen kann

Mythic Quest: Spielentwickler im Schniedelstress
Mythic Quest
Spielentwickler im Schniedelstress

Zweideutige Zweckentfremdung von Ingame-Extras, dazu Ärger mit Hackern und Onlinenazis: Die Apple-TV-Serie Mythic Quest bietet einen interessanten, allerdings nur stellenweise humorvollen Einblick in die Spielebrache.
Eine Rezension von Peter Steinlechner

  1. Apple TV TVOS 13 mit Mehrbenutzer-Option erschienen

  1. Browser: Google warnt Edge-Nutzer vor Chrome-Erweiterungen
    Browser
    Google warnt Edge-Nutzer vor Chrome-Erweiterungen

    Wollen Nutzer des neuen Edge-Browsers auf Chromium-Basis Erweiterungen aus dem Chrome-Webstore installieren, erhalten sie derzeit eine Sicherheitswarnung und in Google-Diensten werden die Nutzer direkt zum Wechsel aufgefordert. Mit anderen Chromium-Browsern wie Opera geschieht dies nicht.

  2. Microsoft Flight Simulator: Landung auf 37.000 Flughäfen möglich
    Microsoft Flight Simulator
    Landung auf 37.000 Flughäfen möglich

    Von der Buckelpiste im Regenwald bis hin zum internationalen Großflughafen: Nach Angaben von Microsoft werden alle 37.000 Flughäfen der Welt im Microsoft Flight Simulator enthalten sein. Im Vorgänger waren es lediglich 24.000.

  3. Mobilfunk: Vodafone verdoppelt Datenrate seiner 5G-Stationen
    Mobilfunk
    Vodafone verdoppelt Datenrate seiner 5G-Stationen

    Vodafone erhält Zugriff auf seine ersteigerten Frequenzen und kann im 5G-Netz von 500 MBit/s auf 1 GBit/s erhöhen. Mittelfristig wolle man das Koaxialnetz auf bis zu 10 GBit/s aufrüsten.


  1. 14:03

  2. 12:35

  3. 12:20

  4. 12:00

  5. 11:54

  6. 11:46

  7. 11:38

  8. 11:25