%DATE() und Datums-/Zeitformate

  • Angeblich kann %DATE ja länderspezifische Formate ausgeben.

    Nur schert sich das nicht um die übliche TheBat!-Formstrings für die Ausgabe.

    Code
    %DATE("ddd, d mmm yyy tt +0100 '(MEZ)'","EN")


    ergibt leider eine falsche Ausgabe:
    Thu, 15 mmm 2011 tt +0100 (MEZ)

    Wenn ich jetzt auf der Microsoft-Seite
    http://msdn.microsoft.com/en-us/library/…8(v=VS.85).aspx
    http://msdn.microsoft.com/en-us/library/dd317787(VS.85).aspx
    nachsehe, müsste das eigentlich so sein:

    Code
    %DATE("ddd, d MMM yyy tt +0100 '(MEZ)'","EN")

    Stattdessen hilft nur:

    Code
    %DATE("ddd, d MMM yyy","EN") %TIME="HH:mm:ss" +0100 (MEZ)

    Wieso zum sind die Formatstrings für %DATE= udn %DATE() anders :cursing:

    Da ist TheBat inkonsistent oder Buggy? Featuritis und schlechte Logik bei den Makros.

    Und wenn die Hilfe so uralt und inkonsistent ist, fängt die stundenlange Websucherei (auch hier) an. :thumbdown:


    The Bat! Pro 11.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.4.x | XMP + Regula

    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.

    3 Mal editiert, zuletzt von GwenDragon (15. Dezember 2011 um 10:53)

  • Laut der MS-Seite ist der Parameter t, in welcher Ausprägung auch immer, gar nicht für Datumsangaben (und damit für die Verwendung mit %DATE) vorgesehen. Dass der von dir vorgeschlagene String somit z.T. nicht funktioniert, ist m.M.n. verständlich. Dass man anstatt Kleinbuchstaben für die Monatsangabe Großbuchstaben verwenden muss, geht auch klar aus der MS-Spezifikation hervor.

    Ritlabs hat zwar die Funktionalität an sich laut Microsoft korrekt implementiert, aber im Vergleich zu bereits vorhandenen Funktionensparamtern nicht angeglichen. Ein normaler User wird die Großschreibung an dieser Stelle nicht erwarten. Ein Verweis auf die Entwickler-Referenz dürfte zwar Software-Entwicklern nichts ausmachen, der normale User, der einfach nur ein Makro verwenden will, will sich nicht in eine Dokumentation für Entwickler einlesen. Ich gehe aber davon aus, dass in der nächsten Version der Hilfe-Datei, das einfließen wird.

  • Interessant an dieser Stelle ist die Tatsache, dass der Parameter "L", welcher laut Ritlabs die lange Datumsangabe ergeben soll, eine weitere Angabe der Ausgabesprache nicht berücksichtigt, egal an welcher Stelle das "L" steht:

    Code
    %DATE("ddd, d MMM yyy","EN")

    ergibt korrekterweise Thu, 15 Dec 2011

    Code
    %DATE("ddd, d MMM yyy","EN",L")

    und

    Code
    %DATE("ddd, d MMM yyy","EN",)

    ergeben fälschlicherweise Donnerstag, 15. Dezember 2011

  • Mich ärgert, dass Ritlabs verschieden Kürzel für die Formate bei den Datums-/Zeit-Makros verwendet.
    Mal funktioniert mmm mal nur MMM.
    Sowas ist Schrott. <ironie> Als nächste fehlt nur noch, dass sie noch extra spezielle sprintf-Formate verwenden.
    Schlimm genug, dass es keine vernünftigen Konvertierungsroutinen gibt und auf externe Plugins zurück gegriffen werden muss, die wieder eigenbrötlerisch Formatstrings verwenden.


    The Bat! Pro 11.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.4.x | XMP + Regula

    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.

  • Code
    %DATE("ddd, d MMM yyy","EN",L")

    und

    Code
    %DATE("ddd, d MMM yyy","EN",)

    ergeben fälschlicherweise Donnerstag, 15. Dezember 2011


    Ich habe das so verstanden, dass man bei TB! %DATEEN benutzen sollte, damit das US-Format erreicht wird. Es ergibt dann richtigerweise Thursday, December 15, 2011.

  • %DATEEN lässt aber keinerlei andere Ausgabeformatierung zu!
    Das ist ja immer das Problem bei den Makros.


    The Bat! Pro 11.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.4.x | XMP + Regula

    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.

  • Das Format von DATEEN ist ja leider nicht flexibel udn z. B. nicht mit XMP nutzbar. Da muss eine völlig bescheuerte Klimmzüge machen wie folgender Thread zeigt Kalenderwoche?


    The Bat! Pro 11.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.4.x | XMP + Regula

    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.

  • Um %DATEEN geht es ja hier gar nicht. Grundsätzlich ist ja die Angabe eines Parameters zur Angabe der Ausgabesprache flexibler. Die Intention der Entwickler war wohl die, ein paar Date-Makros mit zusätzlichen Optionen auszustatten, damit man an anderer Stelle auf ein paar andere Makros verzichten kann, z.B. auf %DATEEN oder %DATESHORT. Mit dem Time-Makro ist wohl das Gleiche angedacht. Durch zusätzliche Parameter könnte man mit dem ursprünglichen Time-Makro das Gleiche erreichen wie jetzt mittels %TIMELONG und %TIMEEN. Im Grunde ergibt sich daraus nicht nur größere Flexibilität, sondern auch ein Abbau von Inkonsistenzen.

    Wenn man das lange Format auf Englisch haben möchte, dann bleibt nichts anders übrig, da "L" wohl nur auf Deutsch funktioniert.

    Was meiner Meinung nach so nicht gewollt ist.
    Wie oben schon gesagt: Ich finde, wenn alles richtig funktioniert, braucht ein Makro für das Datum und je einen Parameter für die Ausgabesprache und die Ausgabelänge. Das "L" ist meiner Ansicht nach noch nicht richtig implementiert.

  • Ja, es geht nicht um DATEEN.
    Ich weiß ja, was ich machen wollte. Und bin nur über die Inkonsistenzen bei den Formatzeichen bei den Zeit-Datumsmakros gestolpert.

    Ich würde begrüßen,. wenn sich Ritlabs auf bestimmte Kürzel einigt. Es kann nicht sein, dass einmal mmm und einmal MMM verwendet werden muss.
    Aber diese Hoffnung ist eher an den Weihnachtsmensch zu richten.


    The Bat! Pro 11.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.4.x | XMP + Regula

    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.

  • Hahaha. Nein, kein Bug. Meinetwegen.
    Aber dann darfst du dir aussuchen, ob Ritlabs nur eine völlig abstruse Beschreibung der erweiterten Möglichkeiten der Datums- und Zeitmakros abgeliefert hat oder doch beim Programmieren gemurkst hat.
    Beschreibung falsch oder Schnittstelle für die Programmierung des Makros falsch oder Bug in TheBat. Oder alles zusammen.


    The Bat! Pro 11.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.4.x | XMP + Regula

    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.

  • Code
    %DATE("L", "RU")
    %DATE("L", "EN")
    %DATE("L", "DE")


    liefert korrekt

    Code
    16 декабря 2011 г.
    Friday, December 16, 2011
    Freitag, 16. Dezember 2011

    Aber diese Beispiele beinhalten ja auch keine Angaben zur Datumsformatierung. Der "L"-Parameter funktioniert IMO nicht richtig in Kombination mit der Anzeigesprache UND einer Datumsformatierung.

    EDIT: Möglicherweise war ich zu schnell mit voreiligen Schlüssen. Wenn man Parameter "L" verwendet, braucht man ja im Grunde auch keine Angabe einer Datumsformatierung. "L" ersetzt ja quasi ein "dddd, dd. MMMM yyy".

    Einmal editiert, zuletzt von mse (16. Dezember 2011 um 16:02)

  • EDIT: Möglicherweise war ich zu schnell mit voreiligen Schlüssen. Wenn man Parameter "L" verwendet, braucht man ja im Grunde auch keine Angabe einer Datumsformatierung. "L" ersetzt ja quasi ein "dddd, dd. MMMM yyy".

    Eben. Deswegen schrieb ich, dass da kein Bug zu sein scheint, weil man auch mit %DATE ein langes US-Format erreichen kann. Will man ein kurzes, lässt man den Parameter "L" ganz weg. %DATEEN ist damit jedenfalls entbehrlich.

    Edit:
    %DATE("L", "RU") liefert übrigens ein nicht vollständiges Resultat, da der Wochentag fehlt, aber das soll uns egal sein. ;)