Hallo, ich arbeite momentan an einer kleiner Zeitmaschinen-Simulation auf Basis eines Raspberry Pi Pico. Man kann die Zeit mithilfe eines Drehgebers einstellen und nachdem mithilfe eines Buzzers die Geräusche einer Zeitreise simuliert wurden, stellt sich die integrierte RTC auf die angegebene Zeit ein. Die aktuelle Zeit wird immer auf einem LCD angezeigt. Die integrierte RTC lässt sich aber nur auf Zeiten nach Christus und maximal auf das Jahr 4095 stellen, was für eine Zeitmaschine eine große Beschränkung ist. Ich habe schon versucht, die RTC so nah wie möglich an die gewünschten Zeit zu stellen und die Differenz zu speichern, sodass immer das aktuelle Jahr ausgerechnet werden kann. Dabei kommt es aber logischerweise zu Fehler bei Schaltjahren. Ich suche nun eine RTC, die mit solch frühen und späten Zeiten umgehen kann. Wenn möglich sollte man sie mit I2C ansteuern können. Gibt es kein Modul, was meinen Anforderungen entspricht, bin ich auch bereit, etwas selber zu bauen. Ich bräuchte dabei allerdings etwas Hilfe.
Vincent N. schrieb: > Ich suche nun eine RTC, die mit solch frühen und späten Zeiten umgehen > kann. Wozu sollte es die geben. Eine RTC soll die aktuelle Uhrzeit bereit stellen. Wenn du andere Zeiträume benötigst, verwende einen Mikrocontroller.
Vincent N. schrieb: > lässt sich aber nur auf Zeiten nach Christus und > maximal auf das Jahr 4095 stellen Könnte man nicht für einen solchen speziellen Fall die "Uhr" rein in Software programmieren, so daß gar keine extra-Hardware erforderlich ist? Um echte Genauigkeit und Gangreserve kann es bei dieser Idee doch nicht gehen. mfg
Hallo Warum nicht "einfachen" Zähler mit einstellbaren Preset der sowohl rückwärts als auch vorwärts zählen kann. Dann noch einen einstellbaren Takt der eventuell langsam "ausrollt" bzw. "hochfährt" Sollte in Software machbar sein, wird aber nicht so einfach sein, bzw. man muss sich den Code (Sketch) zusammen klicken und ein wenig (mehr) anpassen. Wobei: Solche "Zeitmschinen" wurden doch bestimmt schon mehrfach realisiert (Nachbau aus dem Film "Die Zeitmaschine" - wobei da so einiges an Mechanik notwendig wäre oder von "Zurück in die Zukunft" von der ich sicher bin das diese Anzeige schon mehrfach realisiert wurde - ob Dokumentiert mit fertigen Code für einen Arduino ist halt die Frage)
Vincent N. schrieb: > RTC RTC heißt nun mal Echtzeituhr. Und das ich die Zeit, die diese Uhr erleben könnte plus ein wenig Reserve. Um irgendwelche Wochentage zu irgendwelchen Datumsvorgaben zu berechnen gibt es Tabellen und Formeln. Vincent N. schrieb: > auch bereit, etwas selber zu bauen. Ich bräuchte dabei allerdings etwas > Hilfe. Wo klemmt es denn?
Vincent N. schrieb: > Ich suche nun eine RTC Nein, RTC = Real Time Vounter, nicht FTC Fake Time Counter. Einen Fake Time Counter kannst du durch Speichern einer Zeitdifferenz zur Real Time programmieren.
Vincent N. schrieb: > Ich habe schon versucht, die RTC so nah wie möglich an die gewünschten > Zeit zu stellen und die Differenz zu speichern, sodass immer das > aktuelle Jahr ausgerechnet werden kann. Dabei kommt es aber > logischerweise zu Fehler bei Schaltjahren. Dann nimm doch die allgemeine intergalaktische Zeit als Zeitnormal. Die Berechnung der Schaltjahre ist doch nur für die jüngste Zeit gedacht. In einer Million Jahre läuft die doch auch aus dem Ruder. Weitere Hinweise könnte man über Dr. Who erhalten. Der war schon einmal am Ende der Zeit. https://de.wikipedia.org/wiki/TARDIS mfg klaus
Klaus R. schrieb: > In > einer Million Jahre läuft die doch auch aus dem Ruder. Viel früher: so circa nach 3200 Jahren. Und vor 1582 gilt der Gregorianische Kalender ebenfalls nicht. Gruß Anja
Anja schrieb: > Und vor 1582 gilt der Gregorianische Kalender ebenfalls nicht. Davor galt der Julianische Kalender. Der wurde von Julius Cäser eingeführt. Und das Jahr 0 gibt es nicht. Vielleicht wäre das Julianische Datum (nein, nicht der Kalender) was für dich.
Anja schrieb: > Viel früher: so circa nach 3200 Jahren. Das lässt sich leicht in den Griff kriegen, indem ein Schalttag gestrichen wird. Da hat sich der Gesetzgeber nur noch keine Gedanken drum gemacht. Das hat sich bei Zeitreisen bisher aber noch nie als Hindernis erwiesen. > Und vor 1582 gilt der Gregorianische Kalender ebenfalls nicht. Schaltjahre gab es auch vorher schon.
Dem TO scheint selber schon klar geworden zu sein, dass er garnicht weiß, was er will. Und dann kann er auch niemandem klar machen, was er von der ursprünglichen Idee mit der RTC sichtbar machen wollte. Da werden sich hier noch ein paar Leute angiften und dann ist schnell die Grundfrage vergessen. Gute Nacht
Kurt schrieb: > Da werden sich hier noch ein paar Leute angiften und dann ist schnell > die Grundfrage vergessen. Ich fürchte eher, dass dem TO noch einiges an Grundlagen zum Kalender fehlt. Alleine die Tatsache, dass sich die Tageslänge über größere Zeiträume deutlich ändert, hat er in seiner Betrachtung noch nicht erfasst. Seine Uhr wird bei der Anzeige der Sekunden nicht nur den Bereich 0...59 abdecken müssen, sondern mit Fortgang der Welt auch immer häufiger die Sekunde 60 berücksichtigen müssen, wie es aktuell nur alle knapp zwei Jahre passiert. Aber das wird mehr ;-) Schon an diesen Schaltsekunden scheitert aktuell IMHO jede RTC.
Die Julianische Zeit wäre was für Dich. Allerdings wirst Du diese immer berechnen und von der RTC abkoppeln müssen, d.h. diese Zeit "läuft in einem zur RTC unabhängigen Zähler". DEr julianische Zähler wird mit dem Sekundentakt der RTC getriggert. Allerdings gibt es bei der Umrechnung einen kleinen Haken und das ist die Kalenderumstellung 1582. Kann man aber in der Umrechnungsroutine berücksichtigen. Ich habe so etwas mal in Pascal gemacht. Wenn die Zeitmaschine auch nach dem Ausschalten wieder korrekt laufen soll, muß man sich den den letzten julianischen Zeitpunkt und die Zeit der RTC zum Ausschaltzeitpunkt merken. Nach dem Reboot liest man zunächst die RTC aus und kann damit die Differenzsekunden zum letzen Ausschalten berechnen. Mit der gespeicherten julianischen Zeit kann dann der "aktuelle" julianische Zeitpunkt berechnet werden.
Lösung hab ich leider auch keine. evtl. gibt es ja eine 'Software-RTC-Library' für Arduino. Aber warum sollte sich eine Zeitmaschine um Schaltsekunden/Minuten/Stunden/Tage kümmern? Das ist ein soziales Konstrukt. Eine Zeitmaschine müsste sich eher an Naturgesetzen orientieren.
Chr. M. schrieb: > Aber warum sollte sich eine Zeitmaschine um > Schaltsekunden/Minuten/Stunden/Tage kümmern? Von einer Zeitmaschine, die mich in die Zeit der Dinosaurier zurück versetzt, würde ich schon erwarten, dass die Anzahl der Tage pro Jahr halbwegs realistisch ist. Wenn das Jahr vor 70 Mio Jahren real 372 Tage zu 23 ½ Stunden hatte, erwarte ich schon, dass der Kalender mir dann nicht etwas von 365 Tagen erzählt.
Chr. M. schrieb: > Eine Zeitmaschine müsste sich eher an Naturgesetzen orientieren. Beruht Gezeitenreibung nicht ab Naturgesetzen?
Chr. M. schrieb: > Eine Zeitmaschine müsste sich eher an Naturgesetzen orientieren. Dann ist es aber keine Zeitmaschine mehr. ;-)
Kennt jemand eine Library, die diese Sachen berechnen kann? Ich würde dann den ausgewählten Zeitpunkt in das julianische Datum umrechnen und das dann immer weiter zählen. Jede Sekunde wird dann daraus die aktuelle Zeit berechnet und das Ergebnis angezeigt. Eine solche Library wäre aber bestimmt recht umfangreich, daher glaube ich, dass es mit dem Mikrocontroller doch nichts wird. Wahrscheinlich werde ich einen "echten" Raspberry Pi benutzen.
Vincent N. schrieb: > Eine solche Library wäre aber bestimmt recht umfangreich, daher glaube > ich, dass es mit dem Mikrocontroller doch nichts wird. Wahrscheinlich > werde ich einen "echten" Raspberry Pi benutzen. Überleg dir erstmal was du genau von deiner Uhrenroutine/(RT)C GENAU erwartest.
Wolfgang schrieb: > Schaltjahre gab es auch vorher schon. Ja, aber zu oft. Eben deswegen wurde ja der Gregorianische Kalender eingeführt, der die Sache schon deutlich besser abbildete und das mit nur zwei bemerkenswert einfachen Zusatzregeln.
Vincent N. schrieb: > Dabei kommt es aber > logischerweise zu Fehler bei Schaltjahren. Wenn Archäologen eine Zeitangabe machen, z.B. 3214 vor Christus, dann haben die sicher keine Schaltjahre berücksichtigt. Zur Klimaforschung werden in der Arktis Bohrkerne aus dem Eis herausgeholt und untersucht. Da zählt man bestenfalls die Jahre so ähnlich wie Jahresringe bei Bäumen. mfg Klaus
Vincent N. schrieb: > Kennt jemand eine Library, die diese Sachen berechnen kann? > > Ich würde dann den ausgewählten Zeitpunkt in das julianische Datum > umrechnen und das dann immer weiter zählen. Jede Sekunde wird dann > daraus die aktuelle Zeit berechnet und das Ergebnis angezeigt. > > Eine solche Library wäre aber bestimmt recht umfangreich, daher glaube > ich, dass es mit dem Mikrocontroller doch nichts wird. Also, der Gregorianische Kalender hat in meiner Implementierung für einen ATtiny knapp ein kByte. Ist allerdings auch mit solchen Sachen wie den Umgang mit Kalenderwochen nach deutscher Norm und den gesetzlichen Feiertagen (zumindest denen eines bestimmten Bundeslands) gerüstet, da könnte man also für deine Anwendung noch einiges rauswerfen. Ich würde mal schätzen, dass dann so etwa 0,7 kByte über bleiben. Der Julianische Kalender ist noch einfacher gestrickt, wenn man den Support dafür mit einbaut, dürfte man wieder ungefähr bei einem kByte landen. Übrigens: auch der Geltungsbereich des Julianischen Kalenders ist recht eng begrenzt. Was willst du außerhalb machen? Babylonischer, sumerischer, ägyptischer oder chinesischer? Wobei es auch bei denen wieder Varianten und Geltungbereiche gibt... Sprich: Die Idee ist schon Bullshit. Hoch-trollig.
Klaus R. schrieb: > Wenn Archäologen eine Zeitangabe machen, z.B. 3214 vor Christus, dann > haben die sicher keine Schaltjahre berücksichtigt. Wenn eine Sonnenfinsternis 720 v.Chr. allerdings plötzlich nicht in Babylon, sondern irgendwo auf dem Atlantik stattfindet, weil die Tageslänge falsch gerechnet ist, kann das für eine Zeitreise schon eine böse Überraschung sein. Da braucht man nur in historische Aufzeichnungen zu gucken, die die Archäologen aufgetan haben.
c-hater schrieb: > Der Julianische Kalender ist noch einfacher gestrickt, wenn man den > Support dafür mit einbaut, dürfte man wieder ungefähr bei einem kByte > landen. > > Übrigens: auch der Geltungsbereich des Julianischen Kalenders ist recht > eng begrenzt. Was willst du außerhalb machen? Ich meine das julianische Datum (https://de.wikipedia.org/wiki/Julianisches_Datum), nicht den julianischen Kalender.
Vincent N. schrieb: > Eine solche Library wäre aber bestimmt recht umfangreich die Grundfunktionen, also 32-Bit binär nach YYYY-MM-DD HH:MM:SS und zurück kosten auf einem Cortex-M4 weniger als 500 Byte. Also kein Grund, ein spezielle RTC zu suchen. Außerdem muss die ja nur die Zeit überbrücken in der der Rechner nicht läuft. Ein ähnlicher Kalender, aber für die Jahre 1583 bis 3267 und mit 24-Bit Datum plus 24-Bit Zeit, läuft auf einer 8-Bit CPU so nebenher und braucht noch etwas weniger Bytes (die Funktionen für 24-Bit Arithmetik hat man auf so einem Rechner ja sowieso). Außerhalb dieses Zeitraum wird es eher noch einfacher. Wolfgang schrieb: > Schon an diesen Schaltsekunden scheitert aktuell IMHO jede RTC. Ganz im Gegenteil, sie zeigt jederzeit die wahre Zeit an, während UTC einen sägezahnförmigen Fehler bis zu 0.9s macht ;) Natürlich muss man den Oszillator so trimmen, dass sie im Mittel über einige Jahrzehnte mit UTC übereinstimmt.
Ich würde ja einfach erst einmal mit der Differenz (in Sekunden) zur aktuellen Zeit anfangen...
Vincent N. schrieb: > Ich meine das julianische Datum > (https://de.wikipedia.org/wiki/Julianisches_Datum), nicht den > julianischen Kalender. Beschäftige Dich mal intensiv mit Datumsberechnungen. Wenn Du ein julianisches Datum hast, dann hast Du im Prinzip auch einen julianischen Kalender. Empfehlenswert zum Thema sind da Astromieforen bzw. Astronomiebücher, da in der Astronomie auch heute noch die julianische Zeitrechnung eine große Rolle spielt.
Vincent N. schrieb: > ich arbeite momentan an einer kleiner Zeitmaschinen-Simulation auf Basis > eines Raspberry Pi Pico. Man kann die Zeit mithilfe eines Drehgebers > einstellen und (...) die aktuelle Zeit wird immer auf einem LCD > angezeigt. Vincent N. schrieb: > Kennt jemand eine Library, die diese Sachen berechnen kann? Die Beschäftigung mit den verschiedenen (auch historischen) Kalernderformaten und der modernen Zeitfortschreibung kann schon echt interessant sein. Aber ich habe so meine Zweifel, ob Dich selbst das eigentlich interessiert. Wir haben hier im Forum jedenfalls keine Idee davon, was Deine Zeitmaschinen-Simulation eigentlich simulieren soll. Daher wissen wir auch nicht, was "diese Sachen" sind, die eine Library berechnen soll. Vielleicht - wenn Dir selbst klar ist, was die Library eigentlich GENAU machen soll - kannst Du sie ja auch selbst schreiben? (Auch ein cooles Projekt, wenn man etwas gefunden hat, was man selbst und andere brauchen können, aber noch keiner vorher gemacht hat) Um einfach eine Datums/Uhrzeit-Anzeige auf einem Display mit einem bestimmten Offset zur "offiziellen" Lokalzeit laufen zu lassen, bedarf es keiner speziellen Libraries.
Vincent N. schrieb: > Die integrierte RTC lässt sich aber nur auf Zeiten nach Christus und > maximal auf das Jahr 4095 stellen, was für eine Zeitmaschine eine große > Beschränkung ist. Ja, das wirft auch mich bei meiner Zeitmaschine immer zurück. Der Fluxkompensator funktioniert zwar schon, aber das mit der Zeiteingabe funktioniert nicht so recht. Das mit den Zeiten v. Christus ist aber logisch. Oder meinst Du, Cäsar hat ein Minus vor seine römische Jahreszahl gemacht und zu der Geburt von Jesus haben sie von -1 auf 0 gezählt? Es musste den Leuten ja auch erst klar werden, was da für'n Heini angefahren kam. Hinzu kommen die unterschiedlichen Kalender, welche Du je nach Zeit aktivieren musst. Im Jahr 2037 oder so läuft der 32-Bit Unix Timestamp über und wird dann mit 64 Bit laufen und wird dann einen Umfang von 280 Mrd. Jahren verarbeiten können. (Wenn er das nicht jetzt schon tut ...) Also husch doch mal eben kurz nach 2037, hol Dir die Sourcen und bau sie ein. Und wenn Du das ganze signed machst, dann kannst Du von 140 Mrd v.Chr. bis 140 Mrd n.Chr. reisen. Du musst dann nur noch passende Funktionen für die unterschiedlichen Kalender einbauen. Viel Erfolg! Gruß Jobst
Hier wird viel gerätselt (und geschwafelt), vom TO kommen aber auch keine präziseren Anforderungen. Zeitreise mit µC würde für mich heißen: Ich habe eine Echtzeituhr mit Datum und Uhrzeit, dann reise ich x Tage und y Tagesbruchteile vorwärts/rückwärts. Dann rechne ich einfach mit Offset zu den Daten der Echtzeituhr: Der gute Jean Meeus hat Rechenschritte für die Umwandlung des aktuellen Datums in die Julianische Tageszahl veröffentlicht. Diese Tageszählung fängt am 1. Januar -4712 an. Da hatte noch keine Kultur einen Kalender! - Dazu liefert er auch die Rechenschritte, um von der (um x Tage veränderten) Julianischen Tageszahl auf das Datum im julianischen, oder gregorianischen Kalender zu kommen. Das sind in exakter Ganzzahlrechnung deutlich unter 2 K auf einem Atmel. Dann noch ein paar 100 Byte, für den Offset (y) in Stunden, Minuten und Sekunden. - Null Problem. Nun zum Problem: Eine Zeitreise-Lib gibt es mangels Nachfrage nicht. Dazu mag der TO nicht programmieren, Rechnen und Grundschritte zur eigenständigen Problemlösung sind auch nicht sein Ding... Die Glaskugel sagt: Das wird wohl nix.
Der TO hat halt aus einer Bier-Laune heraus spontan sein Vorhaben geschildert, ohne zuvor selbst "hinreichend" nachgedacht zu haben, und ohne überhaupt zu wissen was er selbst eigentlich will. Natürlich kommen dann sinnfreie Fragen heraus. Kann passieren und geschieht hier ja so ca. 10x am Tag! Also Frieden, seit 15 Minuten ist Ostern...
Wolfgang schrieb: > Wenn eine Sonnenfinsternis 720 v.Chr. allerdings plötzlich nicht in > Babylon, sondern irgendwo auf dem Atlantik stattfindet, weil die > Tageslänge falsch gerechnet ist, kann das für eine Zeitreise schon eine > böse Überraschung sein. Oder man hat im Jahr 20000 eine Verabredung und dann ist der Kaffee kalt - aber um so etwas festzustellen muss der TO schon seine Zeitmaschine in echt zum Laufen bringen. Ohne das gilt einfach die angezeigte Zeit, niemand kann was anderes beweisen. Georg
Georg schrieb: > Ohne das gilt einfach die angezeigte Zeit, niemand kann was > anderes beweisen. Die Naturgesetz haben sich als ausgesprochen zuverlässig für unser Alltagsleben herausgestellt. Da muss nichts mehr bewiesen werden und es spricht vieles dafür, dass sie auch in 20000 Jahren noch gelten. Schöne Ostern
Ich verstehe das Problem nicht. Bei dem Projekt kann es sich dich nur um eine Spielerei handeln, irgendwas mit Science Fiction und Zeitreisen. Das ist doch völlig egal, ob die Zeit im Detail korrekt berechnet wird, oder nicht. Hauptsache man kann etwas sehen.
Stefan ⛄ F. schrieb: > Das ist doch völlig egal, ob die Zeit im Detail korrekt berechnet wird, > oder nicht. Hauptsache man kann etwas sehen. Das kommt drauf an. Wenn mehr als Datum/Uhr sehen soll, würde man doch erwarten, dass bei einer Reise in die Vergangenheit eine Sonnenfinsternis am richtigen Ort zur richtigen Zeit statt findet. Aber dann müsste der TO mal formulieren, was außer der Anzeige auf seiner (RT)C noch simuliert werden soll.
Es soll zwar nur das Datum und die Urzeit angezeigt werden, die Uhr soll aber natürlich auch korrekt weiterlaufen. Deshalb muss man Schaltjahre und -sekunden und sonstige Anomalien beachten. Außerdem soll man nur Daten auswählen können, die wirklich existieren. Wenn z.B der 28.2.2020 ausgewählt ist und man den Drehregler für das Datum eins nach rechts dreht, soll daraus der 29.2.2020 werden. Ist aber der 28.2.2017 ausgewählt, soll daraus natürlich der 1.3.2017 werden.
Warum rechnest du nicht einfach mit UTC Sekundenzeitstempel? Formeln zum Umrechnen in lesbare Zeit gibts fix und fertig online und die Zeit lässt sich bis nach dem Ende unserer Zeit einstellen. (Bei Verwendung von uint64_t Variablen)
Vincent N. schrieb: > Außerdem soll man nur Daten auswählen können, die wirklich existieren. > Wenn z.B der 28.2.2020 ausgewählt ist und man den Drehregler für das > Datum eins nach rechts dreht, soll daraus der 29.2.2020 werden. Ist aber > der 28.2.2017 ausgewählt, soll daraus natürlich der 1.3.2017 werden. Das ist tatsächlich der einfachste Teil vom Ganzen und rein dafür gibt es jede Menge "libraries", z.B. localtime() und mktime(). Der Trick dabei ist, dass man eben nicht aufpasst, welcher Tag nach dem 28.2.2017 kommt. Stattdessen erhöht/erniedrigt jeder Schritt am Drehknopf die 64-Bit-Variable um 86400. Stunden- und Minuten-Drehknöpfe würden einfach 3600 bzw. 60 addieren und um den Übertrag um Mitternacht muss man sich auch nicht kümmern. localtime() berechnet dann aus diesen 64 Bit Datum und Uhrzeit für die Anzeige. Bonus: man kann localtime() ganz einfach auf eine andere Zeitzone umschalten. Dabei wird auch automatisch die Sommerzeit berücksichtigt, passend zum Land und zum eingestellten Jahr. Die Sommerzeit-Regeln ändern sich ja doch öfter. Waldfee schrieb: > Warum rechnest du nicht einfach mit UTC Sekundenzeitstempel? > die Zeit lässt sich bis nach dem Ende unserer Zeit einstellen. > (Bei Verwendung von uint64_t Variablen) Meinten Sie: int64_t? Gerade bei einer Zeitmaschine wäre das vorteilhaft ;)
:
Bearbeitet durch User
Weiss man jetzt schon, wann in Zukunft Schaltsekunden eingefügt werden, wann die Winterzeit abgeschafft wird und dann Zeitzonen verändert oder abgeschafft werden? Ich denke, dass so eine Berechnung in ferne Zukunft zwangsläufig eine ungenaue Spielerei sin wird. Ebenso wie die Zeitreise in die Vergangenheit wo andere Kalender galten oder gar keine. So richtig genau kennen wir ja nicht einmal unsere eigene menschliche Vergangenheit. Welcher Kalender galt eigentlich vor der Menschheit? Wen kann man da fragen, und wie?
Wegen "Es musste den Leuten ja auch erst klar werden, was da für'n Heini angefahren kam." Und wegen Ostern: Nehmt ihr mich mit? Die Golgatha-Nummer würde ich schon gerne live angucken ...
Götz schrieb: > Und wegen Ostern: Nehmt ihr mich mit? Die Golgatha-Nummer würde ich > schon gerne live angucken ... Wurde doch bestens verfilmt, schon anno 1979, von Terry Jones.
Stefan ⛄ F. schrieb: > Welcher Kalender galt eigentlich vor der Menschheit? Wen kann man da > fragen, und wie? Frag Sid (Ice age), der weiß das bestimmmt.
Stefan ⛄ F. schrieb: > Weiss man jetzt schon, wann in Zukunft Schaltsekunden eingefügt werden, > wann die Winterzeit abgeschafft wird und dann Zeitzonen verändert oder > abgeschafft werden? Man weiß ja nicht einmal, ob die EU-Parlamentarier es bis zum nächsten fraglichen Datum schaffen, die Sommerzeit neu zu regeln, obwohl das den EU-Bürgern schon vor inzwischen mehreren Jahren zugesagt wurde. ;-) Und für Schaltsekunden ist nur festgelegt, zu welchem Zeitpunkt sie eingefügt werden, falls Bedarf besteht. Wie oft Bedarf besteht hängt z.B. von der Klimaentwicklung und den Gezeiten ab.
Wolfgang schrieb: > Man weiß ja nicht einmal, ob die EU-Parlamentarier es bis zum nächsten > fraglichen Datum schaffen, die Sommerzeit neu zu regeln, obwohl das den > EU-Bürgern schon vor inzwischen mehreren Jahren zugesagt wurde. Ja, weil die Idioten nicht nur die Sommer-/Winter-Umschaltung abschaffen wollten, sondern das gleich mit einer einheitlichen Zeitzone für ganz Europa verknüpfen wollte. Das ist ein klassischer Fall von Over-Engineering: Zu viel gewollt. Ich glaube nicht, dass die Bürger bei der Umfrage eine einheitliche EU-Zeitzone im Sinn hatten.
Bauform B. schrieb: > Meinten Sie: int64_t? Gerade bei einer Zeitmaschine wäre das vorteilhaft > ;) Kommt drauf an, ich hätte zwei uint64 angelegt für plus und minus 1970. Ich weis ja nicht wie weit die Zeitmaschine springen soll :)
Stefan ⛄ F. schrieb: > Ich denke, dass so eine Berechnung in ferne Zukunft zwangsläufig eine > ungenaue Spielerei sin wird. Wie jede Aussage, die die Zukunft betrifft... > Ebenso wie die Zeitreise in die Vergangenheit wo andere Kalender > galten oder gar keine. > Welcher Kalender galt eigentlich vor der Menschheit? Wen kann man da > fragen, und wie? Die Astronomen. Der TO hat insofern schon den richtigen Plan: Vincent N. schrieb: > Ich würde dann den ausgewählten Zeitpunkt in das julianische Datum > umrechnen und das dann immer weiter zählen. Jede Sekunde wird dann > daraus die aktuelle Zeit berechnet und das Ergebnis angezeigt. Man benutzt für die Zeitmaschine einfach eine bewährte Zeitskala, die beliebig weit in die Vergangenheit (und Zukunft) reicht. Die Grenze im Jahr -4712 ist eigentlich keine, da beginnt nur ein neuer Zyklus. Also baut man noch einen Zykluszähler dazu. Eine Zeitmaschine sollte sowieso mehrere Anzeigen haben, natürlich JD und MESZ, dazu vielleicht UTC oder Maya oder einen der restlichen 88 Kalender. Wenn man zu weit in die Vergangenheit reist, zeigen manche Anzeigen eben statt der Zeit "underflow" an (oder so).
Bauform B. schrieb: > Wen kann man da fragen, und wie? > Die Astronomen. Die interessieren sich herzhaft wenig dafür, ob der Urknall an einem Montag oder Dienstag stattfand und um wie viel Uhr man dann genau das Abendmahl feiern müsste.
Bauform B. schrieb: > Wenn man zu weit in die Vergangenheit reist, zeigen manche > Anzeigen eben statt der Zeit "underflow" an Das passiert nur, wenn man vor dem Urknall ankommen möchte.
Waldfee schrieb: > Kommt drauf an, ich hätte zwei uint64 angelegt für plus und minus 1970. > Ich weis ja nicht wie weit die Zeitmaschine springen soll :) Interessanter Plan. Nicht nur wie weit, es könnte ja auch sein, dass die Zeit zyklisch ist. Wenn man dann zu weit in die Zukunft reist, kommt man bei -13.8E9 Jahren raus. Das wäre für reale uC natürlich viel angenehmer als ±Unendlich.
Waldfee schrieb: > Bauform B. schrieb: >> Meinten Sie: int64_t? Gerade bei einer Zeitmaschine wäre das vorteilhaft >> ;) > > Kommt drauf an, ich hätte zwei uint64 angelegt für plus und minus 1970. > Ich weis ja nicht wie weit die Zeitmaschine springen soll :) Beim int64 kommt man ca +/- 140 Milliarden Jahre weit. Da das Universum aber noch keine 14 Milliarden Jahre alt ist, sollte das reichen.
Oha, mal eine Präzisierung der Vorstellungen durch Vincent N., wobei man aber sofort merkt, dass er von den realen Problemen der Zeitrechung ungefähr genau NULL,NICHTS kapiert hat: Schaltsekunden sind nicht berechenbar und überhaupt erst seit 50 Jahren mit den technischen Möglichkeiten der Zeitmessung notwendig geworden. Für diese Vergangenheit gibt es Tabellen... Schalttage hängen vom Kalendersystem ab, wobei der Gebrauch dieser Systeme auch zeitlich begrenzt ist. (Die naheliegendste Lösung wurde in meinem letzten Post angedeutet.) Wie das auf einem µC verwirklicht werden könnte, interessiert ihn überhaupt nicht, er will ja nur die fertige Lösung, wobei er die Qualität einer Lösung mangels Verständnis kein bisschen einschätzen, und schon gar nicht wertschätzen kann. Lasst ihn weiter-trollen... Tschüs!
Das Datum muss nur bis zum 2.8.2377 vorgestellt werden können, das wird die Erde weggebombt. Hatte ich letztes bei einer Reise herausgefunden. Zum Glück kam ich gerade noch rechtzeitig zurück.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.