PureBoard

Verfasst: **16.12.2015 23:13**

GPI hat geschrieben: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.).

Heißt "unsupported", dass das niemand mehr auf seinem Rechner zu laufen hat?

GPI hat geschrieben:Abgesehen davon ist die Aussage nicht falsch, weil Mac-os wird unterstützt - nur der 32Bit Prozessor hier nicht.

Ein 32-Bit-Betriebssystem und ein 64-Bit-Betriebssystem sind nunmal 2 verschiedene Betriebssysteme ...

GPI hat geschrieben: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?

Meine Berechnungen, oder z.B. die von wilbert, funktionieren auch in der Regel.

Ich finde auch, das Rad muss nicht ständig neu erfunden werden. Und wenn man nämlich dieses mathematische Problem, dessen Lösung nicht mehr als die 4 Grundrechenarten erfordert, einmal durchschaut und auf allgemeine Weise gelöst hat, kann man die Lösung leicht in jeder Programmiersprache und auf jedem Betriebssystem der Welt implementieren.

Verfasst: **16.12.2015 23:51**

Hallo Kurzer,

schön zu sehen, dass das Date64-Modul Verwendung findet.

Ich möchte dich an dieser Stelle darauf hinweisen, dass es noch Probleme unter Linux (und Mac?) gibt.
So wie es aussieht, wird die Sommerzeit/Winterzeit noch nicht korrekt verarbeitet, weshalb im Beispiel-Code z. B. folgendes ausgegeben wird:

Code: Alles auswählen

Debug FormatDate("%yyyy.%mm.%dd %hh:%ii:%ss", Date())     ; 2015.12.16 22:05:22
Debug FormatDate64("%yyyy.%mm.%dd %hh:%ii:%ss", Date64()) ; 2015.12.16 21:05:22

Sobald ich wieder genug Zeit habe, werde ich versuchen das Problem zu beheben.

NicTheQuick hat geschrieben: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

Zu dem Zeitpunkt, als ich den Code geschrieben habe, fand ich die Schleifen-Variante verständlicher oder die andere Variante ist mir gar nicht eingefallen.

@Nino: Ich habe mich für die Verwendung der OS-internen Datum-Funktionen entschieden, weil bei diesen die Schaltsekunden per OS-Updates immer wieder mal korrigiert werden. Würde man selber die Berechnungen durchführen, müsste man sich auch um die Anpassungen der Schaltsekunden kümmern - und die lassen sich nicht einfach so berechnen.

Verfasst: **17.12.2015 00:10**

Sicro hat geschrieben:@Nino: Ich habe mich für die Verwendung der OS-internen Datum-Funktionen entschieden, weil bei diesen die Schaltsekunden per OS-Updates immer wieder mal korrigiert werden. Würde man selber die Berechnungen durchführen, müsste man sich auch um die Anpassungen der Schaltsekunden kümmern - und die lassen sich nicht einfach so berechnen.

Ja, das stimmt. Die Schaltsekunden müsste man bei meiner Variante selbst einpflegen.
Allerdings wäre noch zu prüfen, ob die in PB implementierten Funktionen der Date()-Library Schaltsekunden berücksichtigen ... da bin ich mir nämlich gar nicht so sicher. Und wenn sie das nicht tun, dann wären eigene Datumsberechnungen die das tun, nicht mit den PB internen Funktionen kompatibel.

Verfasst: **17.12.2015 00:29**

Purebasic mag Schaltesekunden wohl nicht:

Code: Alles auswählen

Debug Date(2015, 6, 30, 23, 59, 60)

Und hier ist auch nur eine Sekunde Unterschied:

Code: Alles auswählen

Debug Date(2015, 7, 1, 0, 0, 0) - Date(2015, 6, 30, 23, 59, 59)

Verfasst: **17.12.2015 05:27**

Nino hat geschrieben:
GPI hat geschrieben: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.).
Heißt "unsupported", dass das niemand mehr auf seinem Rechner zu laufen hat?

Leider nein - wir hätten vermutlich deutlich weniger Probleme in Internet, wenn alle Geräte immer aktuell wären. Bspw. wäre es grob fahrlässig, einen Rechner mit XP ins Internet zu stellen.

Verfasst: **17.12.2015 22:27**

Wegen den Linux-Problem: Wäre es vielleicht nicht doch besser angebracht, die "Date64"-Routinen auf UTC umzustellen und konvertierungsroutinen anzubieten? Das große Problem ist ja, dass die lokale Zeit nicht in einer festen Zeitzone ist, sondern wandern kann. Schimpft sich auch Sommer/Winterzeit oder DaySavingTime (Imo eine der dümmsten Erfindungen überhaupt). Rein praktisch kann es durchaus sein, das 2:03 zeitlich *nach* 2:30 des gleichen Tages einzusortieren ist. Überall wo ein exaktes Log notwendig ist, muss man folgerichtig zwingend die UTC ohne Sommer/Winterzeit benutzen. Von daher würde man gleich drei Fliegen mit einer Klappe beseitigen. Man hat eine Zeitzonenfreie Zeit, man kann das Zeitzonen-Problem beim Linux-Code relativ leicht ausbügeln und man nutzt einen 64Bit Zähler.

p.s.: Spätestens jetzt ist zwingend eine Betriebsystemabhängige Funktion nötig, da man die lokalen Zeiteinstellungen Einstellungen abfragen muss.
p.p.s.: Den Windows-Code kann ich machen, Mac testen (und mit viel gefluche vermutlich auch zusammenstellen), nur bei Linux kann ich nicht helfen. Aber vor den Wochenende wird das nichts.

Verfasst: **18.12.2015 11:48**

NicTheQuick hat geschrieben:Purebasic mag Schaltesekunden wohl nicht:
Code: Alles auswählen
Debug Date(2015, 6, 30, 23, 59, 60)
Und hier ist auch nur eine Sekunde Unterschied:
Code: Alles auswählen
Debug Date(2015, 7, 1, 0, 0, 0) - Date(2015, 6, 30, 23, 59, 59)

Interessant, danke fürs testen!
Ich habe gerade vorgeschlagen, das in der PB-Hilfe zu erwähnen.

Verfasst: **18.12.2015 12:00**

Es bleibt die Frage: Will man wirklich wissen, dass es Schaltsekunden gab? Schaltsekunden gibt es nur, um Erdumdrehung und Sonnenumrundung in Einklang mit unserem Kalender zu bringen, bzw. eher umgekehrt.

Praktisch wird eine Schaltsekunde oft auf eine ganze Minute oder sogar mehr verteilt. Das ist z.B. bei Webservern wichtig, die mit zeitgebundenen Zertifikaten arbeiten. Da würde ein zu langes Verharren auf 23:59:59, bis es auf 0:00:00 umschwenkt, zu Problemen führen. Deswegen verteilt man die zusätzliche Sekunde lieber auf 60 Sekunden, in dem man diese 1/60 länger macht.
Das heißt, es kann von System zu System unterschiedlich sein, wie die Schaltsekunde sich praktisch auswirkt. Und ich sehe deswegen keinen Sinn darin, diese in den Datumsfunktionen zu berücksichtigen.

Verfasst: **18.12.2015 13:13**

NicTheQuick hat geschrieben:[...], bzw. eher umgekehrt.

NicTheQuick hat geschrieben:Praktisch wird eine Schaltsekunde oft auf eine ganze Minute oder sogar mehr verteilt. Das ist z.B. bei Webservern wichtig, die mit zeitgebundenen Zertifikaten arbeiten. Da würde ein zu langes Verharren auf 23:59:59, bis es auf 0:00:00 umschwenkt, zu Problemen führen. Deswegen verteilt man die zusätzliche Sekunde lieber auf 60 Sekunden, in dem man diese 1/60 länger macht.
Das heißt, es kann von System zu System unterschiedlich sein, wie die Schaltsekunde sich praktisch auswirkt. Und ich sehe deswegen keinen Sinn darin, diese in den Datumsfunktionen zu berücksichtigen.

Danke für die Informationen!

Ich selbst habe bisher gut damit gelebt, mich nicht um Schaltsekunden zu kümmern.

Aber ich habe zu wenig Erfahrung mit dem Thema um beurteilen zu können, wo und wann die Berücksichtigung von Schaltsekunden wichtig ist.

Im Moment sehe ich den Knackpunkt vor allem in der Frage der Kompatibilität: Z.B. Dein obiges Beispiel

Code: Alles auswählen

Debug Date(2015, 7, 1, 0, 0, 0) - Date(2015, 6, 30, 23, 59, 59)

wird ein anderes Ergebnis liefern, wenn man es mit dem hier öfter erwähnten "Date64"-Modul berechnet, da dieses ja offenbar Schaltsekunden berücksichtigt. Daher finde ich es v.a. erstmal wichtig, dass jeweils dokumentiert ist, ob Schaltsekunden berücksichtigt werden oder nicht.

Verfasst: **21.12.2015 00:30**

Nur mal kurz reingegrätscht.
Nun habe ich mich doch letztendlich dafür entschieden Wilberts Lösung zu nehmen und auf meine Bedürfnisse anzupassen.

Warum ich mich anders entschieden habe? So genau kann ich das jetzt gar nicht mehr sagen. Möglicherweise hat mir persönlich das Verfahren mit einer vorberechneten Tabelle und der daraus resultierenden hohen Geschwindigkeit besser gefallen - möglicherweise war der Code für mich besser verständlich - ich habe mich dann ja doch ziemlich reingewuselt, um ihn an meinen "designspleen" bzgl. Formatierung und Kommentierung anzupassen.

Dies soll jedenfalls keine persönliche Wertung irgendeiner der vorhandenen Date64 Lösungen sein.

Vielen Dank an alle, die mich beim Date64 Thema mit Hinweisen und Beispielen unterstützt haben, die meinen Horizont überstiegen haben.

(langsam wird für ts-soft, RSBasic und Edel mal nen helles Blondes fällig)

PureBoard

Umgehung des 2038 Limits bei den Datebefehlen?

Re: Umgehung des 2038 Limits bei den Datebefehlen?

Re: Umgehung des 2038 Limits bei den Datebefehlen?

Re: Umgehung des 2038 Limits bei den Datebefehlen?

Re: Umgehung des 2038 Limits bei den Datebefehlen?

Re: Umgehung des 2038 Limits bei den Datebefehlen?

Re: Umgehung des 2038 Limits bei den Datebefehlen?

Re: Umgehung des 2038 Limits bei den Datebefehlen?

Re: Umgehung des 2038 Limits bei den Datebefehlen?

Re: Umgehung des 2038 Limits bei den Datebefehlen?

Re: Umgehung des 2038 Limits bei den Datebefehlen?