| |
| |
|
Clemens
Meier | Gültigkeitsbereich: 1970 bis 2099
Sommerzeit udn GMT werden derzeit noch nicht berücksichtigt (wäre auch nur dann tatsächlich notwendig, wenn man circa den Rechner hinaus Zeiten mit anderen Rechnern vergleichen müsste; synchronisieren)
Angaben von Monats- und Wochentagsnamen sind in Deutsch. Wochennummern nach ISO. Und naturalmente kann man auch bestimmte Daten errechnen, wobei die Funktion das korrekte Datum wieder errechnet bzw. korrigiert.
Die Idee kommt aus dem PHP, der die Funktionen date, mktime, time und isdate kennt, xprofan aber nicht. Aber bei dem was ich tue, brauche immer wieder Datums- und Uhrzeitberechnungen. Und wenn es nur zur Prüfung ist, wie lange ich gearbeitet habe.
- mktime errechnet die Sekunden seit dem 01.01.1970 und dem angegebenen Datum
- fdate formiert das Datum, welches mittels der Sekunden angegeben wurde.
- now ist wie mktime, nur das stets die Zeit zwischen 01.01.1970 und dem Augenblick des Aufrufes berechnet
- isdate prüft, ob das angegebene Datum gültig ist.
Vor allem die Formatierungsmöglichkeiten von fdate sind ziemlich umfangreich, so dass man mit einer Programmzeile auch die seltsamsten Datum- und Uhrzeitkonstruktionen hinbekommt, ohne irgendetwas nachzurechnen.
Di più steht in der hinweis.txt drin und in der datumuhrzeit.prf stehen ein paar einfach Beispiele drin.
Würde mich circa Feedback freuen
Saluto
Clemens |
 |
| |
| |
| |
|
|
Sven
Bader | Ich bin sprachlos! Nicht nur das ich gefunden habe was ich suche, ich bin es auch von php her gewohnt genau so mit Daten zu rechnen. Wenn der Code keine Bugs hat ist er perfekt  |
|
| |
| |
| |
|
|
 | |
| |
| |
| |
|
|
Sven
Bader | Einige Zeilen sind mit Semikolon abeschlossen, darf man das jetzt in Profan? Profan2CPP 1.1 kam mit den Unterscheidungen zwsichen 1 und 2 Parametern in der If-Abfrage nicht zurecht bzw. der C-Compiler meckerte. Das konnte ich alles beheben und es funktioniert wunderbar.
Ich benutze hauptsächlich die now() Funktion um Datumsdistanzen auszurechnen.
Mir ist aufgefallen, dass die Funktionen sichtbar Rechenzeit benötigen im Profan Interpreter. Optimierungsvorschläge meinerseits wäre sowas wie (60*60) als 3600 zu schreiben, glaube nicht das der Compiler hier von selbst optimiert. Die Substr$() würde ich alle durch mid$() ersetzen.
Saluto,
Sven |
|
| |
| |
| |
|
|
Nico
Madysa | Huh?! Semikolon?  Vielleicht ist das eine Möglichkeit von XPSE, mir ist nicht bekannt, dass das mit gewöhnlichem (X)Profan geht. |
|
| |
| |
| |
|
|
Nico
Madysa | OK, da sich bis jetzt niemand gemeldet hat, habe ich mir die Sache angenommen. Folgende zwei Zeilen enden mit Semikolon:
KompilierenMarkierenSeparierenmonatstage$ = 31,28,31,30,31,30,31,31,30,31,30,31;
monatstageS$ = 31,29,31,30,31,30,31,31,30,31,30,31 e>
Da dies die einzigen, mir aufgefallenen, mit Semikolon endenden Zeilen sind, nehme ich an, es handelt sich dabei um einen Schreibfehler oder eine Schreibgewohnheit aus PHP handelt.
Ich würde die Semikolons/Semikoli/Semikola/Semikolen auf jeden Fall entfernen. |
|
| |
| |
| |
|
|
| | xpse bemeckert das in funktion fdate ende% doppelt deklariert ist |
|
| |
| |
| |
|
|
| Hm Michaels Funktion unixtime und Clemens seine Funktion now geben unterschiedliche Werte zurück.  |
|
| |
| |
| |
|
(267)
Deutsch
English
Français
Español
Italia