Umgehung des 2038 Limits bei den Datebefehlen?

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

[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

[GPI]

Date64-Funktionen für alle oses gibts auch hier:
https://github.com/GPIforGit/PureBasic- ... Date64.pbi
(momentan noch auf meinen Bearbeitungszweig von Archiv)

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

[NicTheQuick]

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.

[Nino]

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.

Date64-Funktionen für alle oses gibts auch hier:
https://github.com/GPIforGit/PureBasic- ... Date64.pbi

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.

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.

[GPI]

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

[Derren]

@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

[Kurzer]

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.

Code: Alles auswählen

          While Second > 59
            Minute + 1
            Second - 60
          Wend

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.

[NicTheQuick]

Wobei das hier doch etwas effizienter ist:

Code: Alles auswählen

Minute + Second / 60
Second % 60

Im Gegensatz zu einer Schleife:

Code: Alles auswählen

While Second > 59
	Minute + 1
	Second - 60
Wend

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