Hallo, gibt es in C++ Bibliotheken für Datum- / Zeitberechungen vor dem 1.1.1970 ? Zum Beispiel um zu berechnen, welches Datum sich ergibt, wenn man (rein fiktiv) 2357 Tage zum 1.5.1924 hinzuzählt ? THX
time_t ist eine signed long und kann also auch negative Werte annehmen. Ebenso ist tm_year (Jahr ab 1900) aus struct tm eine signed und darf negativ werden. Man kann also mit den üblichen Zeitfunktionen rechnen, solange man die Wertebereiche nicht überschreitet. Das wiederum ist bei 64 Bit langen long deutlich entspannter.
Die Anzahl der Sekunden vom 1.1.1900 bis zum 1.1.1970 ist angeblich 2208988800 Und es ist möglich, negative Sekunden anzugeben und z.B. gmtime() berechnet dann das korrekte Datum (Tag, Monat, Jahr) auch vor 1970 ? Danke ! http://stackoverflow.com/questions/8805832/number-of-seconds-from-1st-january-1900-to-start-of-unix-epoch According to the Time protocol in RFC 868 it is 2208988800L. The time is the number of seconds since 00:00 (midnight) 1 January 1900 GMT, such that the time 1 is 12:00:01 am on 1 January 1900 GMT; this base will serve until the year 2036. For example: the time 2,208,988,800 corresponds to 00:00 1 Jan 1970 GMT, 2,398,291,200 corresponds to 00:00 1 Jan 1976 GMT, 2,524,521,600 corresponds to 00:00 1 Jan 1980 GMT, 2,629,584,000 corresponds to 00:00 1 May 1983 GMT, and -1,297,728,000 corresponds to 00:00 17 Nov 1858 GMT.
interrupt schrieb: > such that the time 1 is 12:00:01 am on 1 January 1900 GMT; Ist das Unsinn? Richtig wäre doch: > such that the time 1 is 00:00:01 am on 1 January 1900 GMT; Wenn man die ominösen 2208988800 Sekunden nimmt von 1900 bis 1970 und mit negativem in eine time_t (die ja ab 1.1.19070 00:00:00 zählt) steckt, bekommt man tatsächlich den Anfang des Jahrhunderts:
1 | #include <stdlib.h> |
2 | #include <stddef.h> |
3 | #include <stdio.h> |
4 | #include <string.h> |
5 | #include <time.h> |
6 | |
7 | |
8 | int main( int nargs, char **args ) |
9 | {
|
10 | time_t t = (time_t)-2208988800; |
11 | struct tm stm; |
12 | |
13 | stm = *gmtime( &t ); |
14 | |
15 | printf( "%d.%d.%d %02d:%02d:%02d\n", |
16 | stm.tm_mday, stm.tm_mon+1, stm.tm_year+1900, |
17 | stm.tm_hour, stm.tm_min, stm.tm_sec |
18 | );
|
19 | |
20 | return 0; |
21 | }
|
Zumindest auf einem Rechner, der 64 Bit für time_t hat:
1 | klaus@i4a:~ > gcc -Wall t.c && ./a.out |
2 | 1.1.1900 00:00:00 |
:
Bearbeitet durch User
Klaus W. schrieb: > Ist das Unsinn? Richtig wäre doch: >> such that the time 1 is 00:00:01 am on 1 January 1900 GMT; "00:00:01 am" gibt es nicht. Entweder zähle ich im 24 Stunden Modus, dann gehen die Stunden von 0 bis 23 oder im 12 Stunden Modus, dann gehen die Stunden von 1 bis 12 am/pm.
interrupt schrieb: > Die Anzahl der Sekunden vom 1.1.1900 bis zum 1.1.1970 ist angeblich > 2208988800 Wieso "angeblich"? Schaltsekunden wurden erst 1972 eingeführt, um größere Abweichungen zwischen UTC und TAI zu vermeiden.
Klaus W. schrieb: > interrupt schrieb: >> such that the time 1 is 12:00:01 am on 1 January 1900 GMT; > > Ist das Unsinn? Nö. Die Geisterstunde beginnt 12 AM und endet 1 AM. Um sowas zu verstehen muss man in einem Land aufgewachsen sein, in dem 2x4 Hölzer 1½×3½ inches messen und die Unze je nach Inhalt anders wiegt. PS: Auch das scheint nicht zu helfen, die blicken da auch nicht durch: https://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight suizidbastler schrieb: > dann gehen die Stunden von 1 bis 12 am/pm. Eigentlich von 12 bis 11. ;-)
:
Bearbeitet durch User
Sofern man unter Windows programmiert, kann man die windows-eigenen Zeitverwaltungsfunktionen verwenden. Da gibt es einerseits die ausformulierte SYSTEMTIME-Struktur (mit Strukturelementen für Jahr, Monat, Tag, Stunde etc.) und andererseits FILETIME. Letzteres ist ein 64-Bit-Wert, der die verstrichenen 100ns-Intervalle seit dem 1. Januar 1601 zählt. Mit FileTimeToSystemTime und SystemTimeToFileTime kann man zwischen den beiden Darstellungen hin- und her-konvertieren. https://msdn.microsoft.com/en-us/library/windows/desktop/ms724950(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms724284(v=vs.85).aspx
Ok, dann scheinen die ja tatsächlich morgens zu meinen mit 12:00:01. Wer mit sechzehntel Pfund pro Quadratfuß seine Reifen aufpumpt, fängt halt auch mit 12 an zu zählen.
Klaus W. schrieb: > Ok, dann scheinen die ja tatsächlich morgens zu meinen mit 12:00:01. > Wer mit sechzehntel Pfund pro Quadratfuß seine Reifen aufpumpt, fängt > halt auch mit 12 an zu zählen. Das noch grössere Rätsel ist, warum sich sowas halten konnte in einem Land, dass sich praktisch "from scratch" entwickelte, während sogar das verknorzte, festgefahrene Europa zu vernünftigen Einheiten wechselte.
Klaus W. schrieb: > Wer mit sechzehntel Pfund pro Quadratfuß seine Reifen aufpumpt, fängt > halt auch mit 12 an zu zählen. Nehmen die nicht PSI? Es sind 12in pro ft, und dann noch quadriert.
P. M. schrieb: > Das noch grössere Rätsel ist, warum sich sowas halten konnte in einem > Land, dass sich praktisch "from scratch" entwickelte, während sogar das > verknorzte, festgefahrene Europa zu vernünftigen Einheiten wechselte. Genau deshalb. Wenn in den USA Washington etwas durchsetzen will, dann sind viele Bürger geradezu reflexhaft dagegen. Ist auch klar - wer mit seinem Staat über Kreuz war, der wanderte in die USA aus. Das blieb hängen. So selektiert sich das, die Hiesigen haben weniger Probleme mit Autoritäten. Verfahrenstechnisch wärs vermutlich einfacher, wenn einzelne US-Bundestaaten es festlegen. Es steht allerdings zu befürchten, dass es an Tankstellen öfter mal zu Reifenplatzern käme. Sag aber niemand, das wäre absurd. So ist es völlig normal, dass staatsgrenzüberschreitendes Holz an Menge zulegt oder verliert: https://usaerklaert.wordpress.com/2009/10/04/das-nachste-komische-mas-cord-beim-holz/
:
Bearbeitet durch User
Hallo, zur ursprünglichen Frage: es gibt Libraries, ich glaube sogar eine Library, für die Berechnung jedes beliebigen Zeitpunktes in einer Unzahl von Kalendersystemen, egal ob modern westlich, chinesisch, orthodox, jüdisch, Maya usw., auch unter Berücksichtigung der bekannten Verrücktheiten wie der gregorianischen Kalenderreform (da fehlt ein halber Monat) oder der Tatsache, dass es kein Jahr 0 gibt (auch wenn man oft davon spricht). Von Schaltjahren mal ganz abgesehen, aber da weiss niemand, ob unsere Schaltjahrregeln im Jahr 3000 noch gelten. Georg
A. K. schrieb: > Um sowas zu verstehen muss man in einem Land aufgewachsen sein, in dem > 2x4 Hölzer 1½×3½ inches messen und die Unze je nach Inhalt anders wiegt. Am beeindruckensten finde ich da immer noch die Brüche, bei denen unter dem Bruchstrich eine Kommazahl steht, wie es bei Bildsensoren für Kameras üblich ist. So haben viele Kompaktkameras z.B. eine Sensordiagonale von 1/2.3 inches. Ich wüßte nicht mal, wie ich einen solchen selten dämlichen Bruch überhaupt aussprechen sollte. Ein zweikommadrittel Zoll? Georg schrieb: > oder der Tatsache, dass es kein Jahr 0 gibt (auch wenn man oft davon > spricht) Die gab es ja quasi noch nicht, als unsere Zeichrechnung eingeführt wurde. Bei den Stockwerken in Gebäuden in Amerika ist das aber immer noch so. Wenn man runterfährt, kommt nach der 1 gleich die -1.
:
Bearbeitet durch User
Die AM / PM Zeiten sind wirklich unlogisch. Wenn ich die Zeit bei einer Fotofalle einprogrammiere (die haben leider meist nur das am/pm-System), vermeide ich immer die Mittagszeit und programmiere die Kamera entweder am Kern-Vormittag oder -nachmittag. :-)
Georg schrieb: > Hallo, > > zur ursprünglichen Frage: es gibt Libraries, ich glaube sogar eine > Library, für die Berechnung jedes beliebigen Zeitpunktes in einer Unzahl > von Kalendersystemen, egal ob modern westlich, chinesisch, orthodox, > jüdisch, Maya usw., auch unter Berücksichtigung der bekannten > Verrücktheiten wie der gregorianischen Kalenderreform (da fehlt ein > halber Monat) oder der Tatsache, dass es kein Jahr 0 gibt (auch wenn man > oft davon spricht). Von Schaltjahren mal ganz abgesehen, aber da weiss > niemand, ob unsere Schaltjahrregeln im Jahr 3000 noch gelten. > > Georg Super, und WO gibt es die ?
Klaus W. schrieb: > Wenn man die ominösen 2208988800 Sekunden nimmt von 1900 bis 1970 und > mit negativem in eine time_t (die ja ab 1.1.19070 00:00:00 zählt) > steckt, bekommt man tatsächlich den Anfang des Jahrhunderts: > #include <stdlib.h> > #include <stddef.h> > #include <stdio.h> > #include <string.h> > #include <time.h> > > int main( int nargs, char **args ) > { > time_t t = (time_t)-2208988800; > struct tm stm; > > stm = *gmtime( &t ); > > printf( "%d.%d.%d %02d:%02d:%02d\n", > stm.tm_mday, stm.tm_mon+1, stm.tm_year+1900, > stm.tm_hour, stm.tm_min, stm.tm_sec > ); > > return 0; > } Bei mir (Win7, 32 Bit, Eclipse, GCC C++ == MinGW) gibt er aus : "7.2.2036 06:28:16" Auch dann, wenn ich statt "t = (time_t)-2208988800;" eingebe "t = (long)(long)(-2208988800);" :-(
interrupt schrieb: > Super, und WO gibt es die ? http://www.math.harvard.edu/computing/javascript/Calendar/ Da gibts auch den Source Code. Zur Tagesberechnung nimmt man am besten eine Library für den gregorianischen Kalender und rechnet vom/in die anderen um. Dazu gibt es viele Quellen, z.B. uralt (es hat sich ja auch seit Papst Gregor nichts geändert): https://www.freeware.de/download/datumsrechner/ Damit hast du fürs erste genug zu lesen. Georg
interrupt schrieb: > Bei mir (Win7, 32 Bit, Eclipse, GCC C++ == MinGW) gibt er aus : > "7.2.2036 06:28:16" Auf Systemen, wo time_t nur 32 Bit breit ist, ist der früheste darstellbare Zeitpunkt -2147483648, was dem 13.12.1901 um 20:45:52 entspricht. Aufhören tut die Zeitrechnung bei diesen Systemen am 19.1.2038 um 03:14:07 (2147483647). Bis dort sind hoffentlich die meisten auf 64 Bit umgestiegen:)
:
Bearbeitet durch Moderator
Erste Anlaufstelle bei der Suche nach C++-Bibliotheken wäre für mich immer noch Boost. Gerade für solche "Standardprobleme" wie Datums- und Zeitberechnungen findet sich bei Boost eigentlich immer was Passendes: http://www.boost.org/doc/libs/1_59_0/doc/html/date_time.html
Yalu X. schrieb: > Bis dort sind hoffentlich die meisten auf 64 Bit umgestiegen:) Vielleicht wird das auf meine alten Tage ein schöner Nebenverdienst, so wie es das beim y2k-Problem für viele war...
Rolf M. schrieb: > So haben viele Kompaktkameras z.B. eine Sensordiagonale von 1/2.3 > inches. Und wenn man genau hinsieht, stimmt das auch nicht, denn das "inch" ist keines, sondern statt 25.4 nur etwa 16mm lang. Das wiederum rührt aus der vorderen Altsteinzeit her, als Bilddiagonalen von Röhrengeräten gemessen wurden - da wurde der Außendurchmesser der Röhre, nicht aber der Nutzbereich gemessen. Bei Bildaufnahmeröhren (die kreisrund waren) ist somit der Unterschied zwischen Nutzfläche und Außendurchmesser recht groß, und auf die beziehen sich die Sensorgrößenangaben. Ein Sensor mit 1/2.3 Zoll hat damit nicht 11mm Diagonale, sondern nur etwa 7.7mm. Bei vielen Kameras wird übrigens auch die Auflösung des rückseitigen Displays in RGB-Subpixeln angegeben, damit die Zahl größer ist -- hat hier schon mal jemand einen Monitor gesehen, der mit RGB-Subpixeln beworben wird?
interrupt schrieb: > Bei mir (Win7, 32 Bit, Eclipse, GCC C++ == MinGW) gibt er aus : > "7.2.2036 06:28:16" > Auch dann, wenn ich statt "t = (time_t)-2208988800;" > eingebe "t = (long)(long)(-2208988800);" > > :-( Tja, das sind die Segnungen von 32 Bit. Damit schafft man mit time_t nur 1970 +/ 68 Jahre. 1900 fällt da nicht mehr rein. Aber nachdem wir jetzt schon 2015 haben, kann man mal über 64 Bit nachdenken, DOS und Konsorten sind Geschichte.
Klaus W. schrieb: > kann man mal über 64 Bit nachdenken Es gibt seit über 20 Jahren Systeme, die genau das tun. Also, 64-Bit-Werte für die Zeitdarstellung benutzen, nicht darüber nachdenken ...
Hallo, Ohne alles im Detail gelesen zu haben schlage ich noch mal als Suchbegriff "julianisches Datum" vor. Damit hab ich mal ein ähnliches Problem gelöst. (Datumsdifferenz über große Zeiträume) Gruß, Florian
Hallo, interrupt schrieb: > gibt es in C++ Bibliotheken für Datum- / Zeitberechungen vor dem > 1.1.1970 ? Die C++ Library hat eigene Typen dafür: http://en.cppreference.com/w/cpp/chrono Welche Bereiche damit darstellbar sind, hängt wohl aber von der gewählten Clock ab. Die Clock requirments scheinen auf den ersten Blick nicht sehr hoch zu sein, vielleicht loht es sich für Dich, dir das mal anzugucken. mfg Torsten
:
Bearbeitet durch User
Klaus W. schrieb: > Wer mit sechzehntel Pfund pro Quadratfuß seine Reifen aufpumpt, fängt > halt auch mit 12 an zu zählen. Man kann da ja immerhin noch eine Kraft pro Fläche ableiten. Das Schlimmste, was mir begegnet ist, sind die Dickenangaben von Cu-Folien auf Leiterplatten: in Unzen pro Quadratzoll! Das dabei nicht mehr schief geht, wundert mich fast täglich...
>Dickenangaben von Cu-Folien auf Leiterplatten: in Unzen pro Quadratzoll
oder eher Unzen pro Quadratfuss. Ist aber zumindest vorstell-, und
nachvollziehbar. Ich habs auch selbst ausm nichts herausgefunden.
Dass es Unzen Kupfer pro Flaechse sein muss war ja klar, dann brauchts
nur einen Versuch und man ist da.
> Ohne alles im Detail gelesen zu haben schlage ich noch mal als > Suchbegriff "julianisches Datum" vor. > Damit hab ich mal ein ähnliches Problem gelöst. > (Datumsdifferenz über große Zeiträume) Genau. Oder MJD. Modifiziertes Julianisches Datum = Julianisches Datum minus 2 Millionen Tage. Damit lässt sich ruckzuck rechnen. Das wird übrigens im MPEG-Programmstrom für den Datumsstempel benutzt. Erfreut sich auch großer Beliebtheit in der Astronomie.
Klaus W. schrieb: > Ok, dann scheinen die ja tatsächlich morgens zu meinen mit 12:00:01. Die schreiben denn auch "12:00:01 AM" und nicht nur "12:00:01".
Bürovorsteher schrieb: > Erfreut sich auch großer Beliebtheit in der Astronomie. Da sollte man aber besser die 15 Milliarden Jahre seit dem Urknall abziehen, dann hätte man nur positive Zahlen. Georg
Bürovorsteher schrieb: > Genau. Oder MJD. Modifiziertes Julianisches Datum = Julianisches Datum > minus 2 Millionen Tage. Damit lässt sich ruckzuck rechnen. > Das wird übrigens im MPEG-Programmstrom für den Datumsstempel benutzt. Geil. Als wenn es jemals so altes MPEG Material geben würde... :-) Oder wozu soll das gut sein? Gruß, FLo
Rufus Τ. F. schrieb: > Klaus W. schrieb: >> kann man mal über 64 Bit nachdenken > > Es gibt seit über 20 Jahren Systeme, die genau das tun. > > Also, 64-Bit-Werte für die Zeitdarstellung benutzen, nicht darüber > nachdenken ... Die Zahl der Embedded-Systeme, die mit 32 Bit laufen und diese auch für Datum/Uhrzeit nutzen, ist Legion.
Rufus Τ. F. schrieb: > Macht es das besser? Komische Frage. Dir ist sicher bekannt, dass man bei Embedded Systemen nicht jederzeit mal einfach eben so ein Software-Update durchführen kann.
:
Bearbeitet durch User
Gewiss, aber was hat das mit der Fragestellung zu tun? Scroll mal ganz nach oben und lies Dir den ersten Beitrag durch.
Rufus Τ. F. schrieb: > Gewiss, aber was hat das mit der Fragestellung zu tun? > > Scroll mal ganz nach oben und lies Dir den ersten Beitrag durch. Der Themenersteller hat zunächst weder Hardware noch verwendetes Betriebssystem erwähnt, was bei einer solchen Fragestellung nicht hilfreich ist weil viel (wenn nicht gar alles) davon abhängt. Später irgendwann erwähnt er dann ein 32-Bit-System. Voilà. Übrigens lautet die korrekte Antwort auf die allererste Frage des Themenerstellers schlicht "Ja". Besonders hilfreich dürfte dies freilich nicht sein. Ein Königreich für Leute, die ihr Problem präzise beschreiben können...
:
Bearbeitet durch User
Mark B. schrieb: > Später irgendwann erwähnt er dann ein 32-Bit-System. Voilà. Und? Die von mir schon vor einiger Zeit erwähnte 64-Bit-Zeit verwendet Windows seit 1993. Damals war das Windows NT 3.1, ein reines 32-Bit-System. Man braucht keine 64-Bit-CPU für 64-Bit-Arithmetik (ich kann mir ehrlich gesagt auch nicht vorstellen, daß Du mir das mitteilen wolltest).
Wie siehts beim POSIX Standard aus? Irgendwie habe ich das Gefühl, dass sich bei der 32bit time_t häufig auf die Posix Kompatibilität berufen wird.
http://stackoverflow.com/questions/471248/what-is-ultimately-a-time-t-typedef-to sagt ... Unix and POSIX-compliant systems implement the time_t type as a signed integer (typically 32 or 64 bits wide) which represents the number of seconds since the start of the Unix epoch: midnight UTC of January 1, 1970 (not counting leap seconds). Some systems correctly handle negative time values, while others do not. Systems using a 32-bit time_t type are susceptible to the Year 2038 problem. ...
Danke @Klaus. Genaus kann man auch sagen, POSIX macht keine Aussage über die Bitbreite von time_t. Wobei der verlinkte Artikel von signed int spricht. http://pubs.opengroup.org/onlinepubs/9699919799/functions/time.html macht aber (absichtlich?) keine Aussage dazu. Windows(32bit) nutzt 64bit und vermutlich ein Linux(32bit) auch.(?) Cygwin(32bit) nutzt 32bit. Ich glaube die Frage ist eher aus der Historie zu beantworten. Klar wurde früher time_t häufig mit 32bit umgesetzt. Und ja, alte Programme könnten dies benötigen. Aber ist dieses Argument mittlerweile noch relevant?
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.