Seite 1 von 2
Umgehung des 2038 Limits bei den Datebefehlen?
Verfasst: 16.12.2015 02:07
von Kurzer
Hallo,
ich lese gerade mit Erschrecken in der Hilfe, dass die gesamte Date-Lib nur 'Datumse' bis 2038 unterstützt.
Weiß jemand, ob hier eine Erweiterung geplant ist oder wie man das Limit umgehen kann?
Ich habe hier mit der Umsetzung einer Lizenzverwaltung zu tun und da sollte man auch Lifetime-Lizenzen anlegen können, die jenseits der 2038 noch gültig sind. Wäre schade, wenn man wegen des Limits nun auf alle Datefunktionen und das DateGadget verzichten müsste.
Re: Umgehung des 2038 Limits bei den Datebefehlen?
Verfasst: 16.12.2015 02:53
von Derren
Bis 2038 gibt es wahrscheinlich keine 32bit Rechner mehr. Der Unix-Timestamp müsste nur "offiziell" auf 64 bit erweitert werden und das Problem wäre gelöst. Habe eigentlich damit gerechnet, dass das in den letzten Jahren passieren hätte sollen... Naja...
Du brauchst doch sicher keine Sekunden-genaue Zeitangabe für deine Lizenz. Schreib doch einfach "gültig bis 2099" als String und prüfe das Datum bis 2038 mit Date(). Bis es soweit ist (und lange davor), kannst du deine Programme bestimmt entsprechend updaten.
Die Version die du
jetzt programmierst, wird in 2038 wahrscheinlich keiner mehr benutzen.
Zum Thema DateGadget(), hier eine WinApi-Variante, mit der man Daten jenseits von 2038
einzeln (Jahr, Monat etc...) auslesen kann:
http://www.purebasic.fr/german/viewtopi ... 41#p317841
__________________________________________________
Link angepasst
16.12.2015
RSBasic
Re: Umgehung des 2038 Limits bei den Datebefehlen?
Verfasst: 16.12.2015 05:26
von GPI
Date64-Funktionen für alle oses gibts auch hier:
https://github.com/GPIforGit/PureBasic- ... Date64.pbi
(momentan noch auf meinen Bearbeitungszweig von Archiv)
Re: Umgehung des 2038 Limits bei den Datebefehlen?
Verfasst: 16.12.2015 12:31
von Kurzer
Vielen Dank Euch beiden für die links. Damit ist die Sache sehr einfach umsetzbar!
Ein großes Dankeschön an Sicro & ts-soft für das Date64 Module. Das erspart mir eine Menge Arbeit und ich kann mich den eigentlichen Aufgaben weiter widmen.
Sehr schöner Code übrigens, ich hatte einige Aha-Erlebnisse beim Durchstöbern Eures Moduls.
@Derren: Ja das stimmt, bis 2038 wird mein Programm in der jetzigen Form nicht mehr existieren, aber es ist hier Pflicht ein beliebiges Datum als Lizenzende angeben zu können. Mir gruselte daher etwas bei der Rückgabe von -1 aus dem DateGadget(), wenn man Daten außerhalb des Bereichs auswählt. Aber das ist ja dank WinAPI nun alles kein Thema mehr. Ich werde mir das Date64 Module mit entsprechenden Set/Get Prozeduren für das DateGadget() erweitern und dann ist alles in Butter.
Re: Umgehung des 2038 Limits bei den Datebefehlen?
Verfasst: 16.12.2015 12:44
von NicTheQuick
Kurzer hat geschrieben:Ich werde mir das Date64 Module mit entsprechenden Set/Get Prozeduren für das DateGadget() erweitern und dann ist alles in Butter.
Diese Änderungen könntest du ja sogar noch allen zur Verfügung stellen.
Re: Umgehung des 2038 Limits bei den Datebefehlen?
Verfasst: 16.12.2015 16:57
von Nino
Kurzer hat geschrieben:ich lese gerade mit Erschrecken in der Hilfe, dass die gesamte Date-Lib nur 'Datumse' bis 2038 unterstützt.
Weiß jemand, ob hier eine Erweiterung geplant ist oder wie man das Limit umgehen kann?
Diese Frage kommt mit schöner Regelmäßigkeit seit Jahren immer wieder. Entspr. gibt es schon einige Lösungen in den Foren.
Irgendwie wohl doch nicht für alle OS, denn dort steht
"32-Bit not supported on MacOS"
Die ganze Fragestellung hat allerdings gar nichts mit irgendwelchen Betriebssystemen zu tun. Alles was man zur Bearbeitung braucht sind ausreichend "große" Variablen (Quad), Wissen über den Gregorianischen Kalender und solide mathematische Grundkenntnisse. Ich würde nicht im Traum auf die Idee kommen, in solch einem Code auch nur eine einzige
CompilerIf #PB_Compiler_OS = xxx-Anweisung zu verwenden.
Kurzer hat geschrieben:Ein großes Dankeschön an Sicro & ts-soft für das Date64 Module. [...] Sehr schöner Code übrigens
Sorry, aber da kann man durchaus geteilter Meinung sein (s.o.).
Ich würde z.B. lieber diesen
Code von wilbert verwenden.
Re: Umgehung des 2038 Limits bei den Datebefehlen?
Verfasst: 16.12.2015 19:08
von GPI
Nino hat geschrieben:Irgendwie wohl doch nicht für alle OS, denn dort steht
"32-Bit not supported on MacOS"
Ganz ehrlich: Seit 11.7 ist MacOs 64Bit only - es gibt da nicht wie bei Windows eine 32-Bit Fassung. 11.6 wird meines Wissens nach auch nicht mehr gepflegt (laut wikipedia:
Unsupported as of February 25, 2014, though the last security update happened in September 2013.). Abgesehen davon ist die Aussage nicht falsch, weil Mac-os wird unterstützt - nur der 32Bit Prozessor hier nicht.
Und wie man es nimmt. Natürlich kann man alles selbst berechnen - ich persönlich würde hier lieber die Betriebsystemroutinen verwenden - weil die funktionieren in der Regel. Warum das Rad 10x neu erfinden? Hinzu kommt, das der Systemhersteller den Code pflegt - falls sich mal was ändert. Ich denke da bspw. an Schaltsekunden - auch wenn die aktuell ignoriert werden (was schon zu Problemen geführt hat).
Re: Umgehung des 2038 Limits bei den Datebefehlen?
Verfasst: 16.12.2015 19:50
von Derren
Kurzer hat geschrieben:
@Derren: Ja das stimmt, bis 2038 wird mein Programm in der jetzigen Form nicht mehr existieren, aber es ist hier Pflicht ein beliebiges Datum als Lizenzende angeben zu können.
Kann ja sein, aber warum muss dieses Datum aus dem DateGadget kommen.
Ich persönlich habe das DateGadget noch nie gebraucht (abgesehen vom Systray, wo ich es aber auch nur als Übersichtskalender des aktuellen oder nächsten Monats verwende). Jeder "normale" Mensch tippt sein Datum einfach so ein.
Dementsprechend kann man es auch speichern, wie man lustig ist und muss sich nicht von der Limitierung des 32bit Timstamps einschränken lassen.
Aber jetzt hast du ja ne Lösung gefunden
Re: Umgehung des 2038 Limits bei den Datebefehlen?
Verfasst: 16.12.2015 22:26
von Kurzer
Nino hat geschrieben:Kurzer hat geschrieben:Ein großes Dankeschön an Sicro & ts-soft für das Date64 Module. [...] Sehr schöner Code übrigens
Sorry, aber da kann man durchaus geteilter Meinung sein (s.o.).
Ich würde z.B. lieber diesen
Code von wilbert verwenden.
Den Code von Wilbert kannte ich bis eben noch nicht. Um ihn als Module laufen zu lassen, muss man aber wohl noch Hand anlegen.
Was den schönen Code angeht, so beziehe ich mich weniger auf die eigentliche Umsetzung (soweit in die Tiefe jeder einzelnen Prozedur bin ich nicht gegangen), als auf das, was mir als Anwender des Codes das Leben erleichtert.
Ich finde den Code von Sicro & ts-soft gut zu lesen und nachzuvollziehen. Auch finde ich die Korrekturen sehr clever, wenn man z.B. mehr als 60 Sekunden angibt.
Demzufolge könne diese Prozeduren auch mit größeren Zeiten umgehen, wenn diese nur in der Einheit Sekunde ausgedrückt werden. Find ich schon sehr schön.
Dass dort mit CompilerIfs gearbeitet wird stört mich nicht. Man hat sich offenbar dafür entschieden für jede Plattform mit der dort übliche Struktur für DateTime zu arbeiten. Es gibt ja viele Lösungsmöglichkeiten für ein und das selbe Problem.
Wilberts Code durchblicke ich nicht vollständig, aber natürlich schaue ich mir diese Lösung an.
Re: Umgehung des 2038 Limits bei den Datebefehlen?
Verfasst: 16.12.2015 22:58
von NicTheQuick
Wobei das hier doch etwas effizienter ist:
Im Gegensatz zu einer Schleife:
Und mit diese Procedure kann man Tage, Stunden, Minuten und Sekunden normalisieren. Wenn man mag auch so, dass alles bis auf die Tage nicht negativ werden können.
Code: Alles auswählen
EnableExplicit
Procedure normalizeTime(*days.Integer, *hours.Integer, *minutes.Integer, *seconds.Integer, nonNegative.i = #True)
*minutes\i + *seconds\i / 60
*seconds\i % 60
If nonNegative And *seconds\i < 0
*minutes\i - 1
*seconds\i + 60
EndIf
*hours\i + *minutes\i / 60
*minutes\i % 60
If nonNegative And *minutes\i < 0
*hours\i - 1
*minutes\i + 60
EndIf
*days\i + *hours\i / 24
*hours\i % 24
If nonNegative And *hours\i < 0
*days\i - 1
*hours\i + 24
EndIf
EndProcedure
Define.i days, hours, minutes, seconds = -86401;-93784
normalizeTime(@days, @hours, @minutes, @seconds, #False)
Debug "Days: " + days
Debug "Hours: " + hours
Debug "Minutes: " + minutes
Debug "Seconds: " + seconds
seconds + 2 * 86400 ;plus 2 Tage
normalizeTime(@days, @hours, @minutes, @seconds)
Debug "Days: " + days
Debug "Hours: " + hours
Debug "Minutes: " + minutes
Debug "Seconds: " + seconds