Mein erstes kleines Modülchen...

[Patrick Andrieu]

Hallo alle!

Ich wollte keineswegs das Rad neu erfinden, aber nachdem ich festgestellt habe, dass Date::Calc immer noch nicht zur Standarddistribution gehört (auch nicht bei Perl 5.10), kam mir der Gedanke, dass einige Provider es u.U. nicht installiert haben (bei meinem ist es zwar installiert, aber wer weiß, wie's beim Nachbarn aussieht...).

Und deswegen gibt's heute Nudeln und k***** ist erlaubt ;) Also her mit der Tomatensauce!

Viele Grüße aus Frankfurt/Main,
Patrick

[Cheatah]

Hi,

Und deswegen gibt's heute Nudeln und k***** ist erlaubt ;) Also her mit der Tomatensauce!

ich beantrage eine Umbenennung[1] in Date::Heute, oder aber Ansätze einer Internationalisierung. Diese darf gerne aus Tomaten hergestellt werden ;-)

Cheatah

[1] "Date" auf Englisch, weil das Modul in diesen Namespace passt.

[Patrick Andrieu]

Hallo Cheatah!

gibt's heute Nudeln
ich beantrage eine Umbenennung[1] in Date::Heute, oder aber Ansätze einer Internationalisierung.

Dann wäre es aber kein »Modülchen«, sondern ein richtiges Modul, CPAN-reif and so on ;) Ich wollte das Teil ja klein halten (genau 100 Zeilen hat es jetzt). Dann lieber Date::Heute ;)

Diese darf gerne aus Tomaten hergestellt werden ;-)

OK, ich mach ein hash %ketchup ;)

[1] "Date" auf Englisch, weil das Modul in diesen Namespace passt.

Fand ich auch... und Today (oder halt Heute), weil es nicht _Calc_uliert sondern nur das heutige Datum ausgibt.

Viele Grüße aus Frankfurt/Main,
Patrick

[Cheatah]

Hi,

ich beantrage [...] Ansätze einer Internationalisierung.
Dann wäre es aber kein »Modülchen«, sondern ein richtiges Modul, CPAN-reif and so on ;)

das ist wahr. Ich ziehe meinen Antrag zurück ;-)

Diese darf gerne aus Tomaten hergestellt werden ;-)
OK, ich mach ein hash %ketchup ;)

Bitte mit einem Key 'Gorgonzola', daraus mache ich dann lecker Soße für die Noodles ;-)

Cheatah

[Patrick Andrieu]

Hallo Cheatah!

Bitte mit einem Key 'Gorgonzola', daraus mache ich dann lecker Soße für die Noodles ;-)

Aber erst dann, wenn ich 'basilic' als Key in einem neuen Hash %oggigiorno nebst Methode Date::Today->pasta() eingebaut habe!

Oder so...

Viele Grüße aus Frankfurt/Main,
Patrick

[Patrick Andrieu]

Hallo Cheatah!

oder aber Ansätze einer Internationalisierung.

http://www.atomic-eggs.com/cgi-bin/dc.pl

Melde mich später mit dem Code (für die Kritik) ;)

Viele Grüße aus Frankfurt/Main,
Patrick

[Patrick Andrieu]

Re Cheatah!

oder aber Ansätze einer Internationalisierung.

Damit hast Du aber Probleme aufgeworfen, die mich dazu veranlassen, den angepassten Code nicht zu posten. Eben weil angepasst... und an mindestens zwei Stellen sehr unschön. Am Meisten hat mich nicht die Suche nach einer Lösung für das lange Datumsformat geärgert (ich wollte nicht kopieren, also habe ich etwas anderes geschrieben, was lange nicht so elegant ist, wie bei Date::PCalc - wie es bei Date::Calc aussieht, können nur die C-Kenner sehen, ich leider nicht), sondern...

Nein, am Meisten hat mich die Kurzform genervt. Und zwar wollte ich unbedingt eine Kurzform wie:

Heute haben wir den 10.06.

Nur ist es so, dass der Trennpunkt im Deutschen eigentlich gar kein Trennzeichen ist (wie z.B in anderen Sprachen das »/«), sondern gleichzeitig ein Ordinalsuffix. Gelesen wird's ja:

Heute haben wir den zehnten sechsten.

Während (beispielsweise) Franzosen bei:

Le 10/06 (...)

einfach lesen:

Le dix six (...)

wie in anderen Sprachen auch.

Da ich bisher eine Funktion hatte (day_and_month, in der zuallererst hier gezeigten Fassung hieß die noch ddmm), für eben Tag/Monat, die von der Funktion short_date (Tag/Monat/Jahr) neu aufgerufen wurde, hatte ich heute abend das Problem, dass ich bei allen außer lang 'de' kein Trennzeichen mehr vor dem Jahr hatte. Sah so aus:

Today is 10/062008 (english)
   Heute ist 10.06.2008 (deutsch <- hier OK)

Ich hab's zwar quick&dirty hingebogen, gefällt mir aber nicht... Ich überlege mir einen anderen Ansatz, vielleicht eine Funktion, die alle Zeitkomponenten in einem Array zurückliefert, welche die anderen Subs dann auseinandernehmen, je nach dem, was gebraucht wird.

Ach ja... dc.pl vergleicht nun die Ausgaben von Date::Calc, Date::Pcalc [1] und Date::Today. Hierbei merkt man, dass Date::Pcalc etwas veraltet nicht, denn bei der frz. Ausgabe des »langen Datums« steht noch: »Jour, __le__ ...«. Das hat es IMHO nie gegeben (mein alter Herr schrieb an der Schultafel immer: »Mercredi 11 juin 1968« - also ganz ohne »le«). Aus diesem Grund habe ich auch das »den« aus der deutschsprachigen Ausgabe entfernt, weil es langsam »deprecated« wird zum Einen, zum Zweiten das Problem der Deklination mit sich bringt:

Heute haben wir Mittwoch, den 11. Juni.
   Ich habe Dir am Mittwoch, dem 11. Juni gesagt, dass ...

Pedante User können sich die Mühe machen, den String zu splitten, wenn sie das »den/dem/des« wieder haben wollen. Die Anleitung würde ich sogar liefern!

Ansonsten... english ('en') ist default. Objekte werden nun wie folgt erstellt:

use Date::Today;

my $english = Date::Today->new; # oder: Date::Today->new('en');
my $deutsch = Date::Today->new('de');
my $espanol = Date::Today->new('es');

dann:

print $espanol->long_date; #  Miércoles, 11 de junio de 2008

[1] für Perl-interessierte lesende Newbies:

1. Date::Calc ist bei mir installiert (Calc.pm ist in /usr/lib/perl5/Date). Date::Pcalc und Date::Today habe ich einfach in einem Ordner /Date im cgi-bin kopiert, da ich bei meinem Webhoster keine Module selbst installieren kann - und gefragt habe ich noch nicht ;)

2. Da Date::Pcalc die Perl-»Übersetzungen« vom zum Großteil in C geschriebenen Date::Calc ist, aus diesem Grund die selben Funktionen benutzen und zuletzt nicht objektorientiert sind, habe ich im hier zugrunde liegenden Vergleichsskript dc.pl bei Date::Calc alle Funktionen mit qw/:all/ importiert, und dann direkt mit ihrem jeweiligen Namen ansprechen, während ich sie bei Date::Pcalc über die Form Package::Funktion anspreche:

use Date::Calc qw/:all/;
use Date::Pcalc;
use Date::Today;
.
.
.
Language(Decode_Language('Français'));
my $francais = Date_to_Text_Long(Today);
print "Date::Calc  2: ", $francais;
.
.
.
Date::Pcalc::Language(Decode_Language('Français'));
my $pfrancais = Date::Pcalc::Date_to_Text_Long(Today);
print "Date::Pcalc  2: ", $pfrancais;

Viele Grüße aus Frankfurt/Main,
Patrick

[hotti]

Hallo alle!

Ich wollte keineswegs das Rad neu erfinden, aber nachdem ich festgestellt habe, dass Date::Calc immer noch nicht zur Standarddistribution gehört (auch nicht bei Perl 5.10), kam mir der Gedanke, dass einige Provider es u.U. nicht installiert haben (bei meinem ist es zwar installiert, aber wer weiß, wie's beim Nachbarn aussieht...).

Genauso hat es bei mir vor ein paar Jahren auch angefangen:

Date::Calc ist nicht installiert,
ich wollte Kalender,
ergo schrieb ich ein eigenes Modul.

Herzlichen Glückwunsch Patrick!

Viele Grüße,
Hotte

http://rolfrost.de/cgi-bin/xdate.cgi

[hotti]

Ähmm,

falls Du die Mondphasen von 1700-2200 brauchst,

Mail an mir.

Hotti

[Patrick Andrieu]

Hallo hotti!

falls Du die Mondphasen von 1700-2200 brauchst,

So viele brauche ich nicht, aber für »Today« wäre es ein Gimmick, die gerade aktuelle zu ermitteln!

$today->moondingsbums - zunehmend|abnehmend[1]|voll|neu ;)

Danke für die liebe Unterstützung!

[1] Seitdem ich keine Haare auf dem Kopf habe, wiege ich in der Tat weniger - oder liegt's doch an meiner Ernhährung und nicht am Power von Gillette? ;)

Viele Grüße aus Frankfurt/Main,
Patrick

[Adolf]

Hallo Patrick hallo alle,

ich hab hier noch eine Pcalc.pm (de) rumliegen.
Es gab auch mal irgendwo eine gute Beschreibung dazu, die hab ich aber nicht mehr.
Wenn jemand Interesse hat kann ich die ja mal posten oder irgendwo hochschieben.

Gruss A.

[Patrick Andrieu]

Hallo Adolf!

ich hab hier noch eine Pcalc.pm (de) rumliegen.

Von Dir?

Es gab auch mal irgendwo eine gute Beschreibung dazu, die hab ich aber nicht mehr.
Wenn jemand Interesse hat kann ich die ja mal posten oder irgendwo hochschieben.

Mach! Wenn der Code nicht total unleserlich ist, werden wir (zumindest einige andere hier) ihn verstehen!

Viele Grüße aus Frankfurt/Main,
Patrick

[Adolf]

Hallo Patrick,

Von Dir?

ne ne die ist richtig gut (besseres Original).

Naja ich hab sie mal hierher gemacht:
http://www.evilshare.com/7dcdcfbe-8700-102b-a8ce-0007e90cfb90

Der Kopf sieht so aus:
###############################################################################
##                                                                           ##
##    Copyright (c) 1999-2001 by J. David Eisenberg                          ##
##                                                                           ##
##    Documentation and some of the Perl code                                ##
##    Copyright (c) 1993-2001 by Steffen Beyer.                              ##
##    All rights reserved.                                                   ##
##                                                                           ##
##    This package is free software; you can redistribute it                 ##
##    and/or modify it under the same terms as Perl itself.                  ##
##                                                                           ##
###############################################################################

Gruss A.

[Patrick Andrieu]

Hallo Adolf!

Naja ich hab sie mal hierher gemacht:
http://www.evilshare.com/7dcdcfbe-8700-102b-a8ce-0007e90cfb90

Huch, die Seite ist wirklich evil... (Poker-Casino-Popups, Sexlinks)...

Der Kopf sieht so aus:

Ich hab's mittlerweile im CPAN gefunden: http://search.cpan.org/~stbey/Date-Pcalc-1.2/Pcalc.pm. Auf den ersten Blick sieht es so aus, als wäre es nicht, wie Date::Calc, zum Teil im C geschrieben. Denn solche Module mit »C-Teilen« lassen sich nicht einfach kopieren.

Ich schau's mir an, Danke schon mal!

Viele Grüße aus Frankfurt/Main,
Patrick

[Beat]

Habe dein Modul getestet.

use Patrick; #;))

Das funktioniert auf Anhieb.

Allerdings bin ich mit Cheatah einig.
Die Namen sind furchtbar.

mfg Beat

[Patrick Andrieu]

Hallo Beat!

use Patrick; #;))

Hm, solange Perl nicht abuse() einführt, ist es OK.

Agesehen davon, bin ich mit bald 50 schon ziemlich »used« ;)

Viele Grüße aus Frankfurt/Main,
Patrick

[Struppi]

Ich wollte keineswegs das Rad neu erfinden, aber nachdem ich festgestellt habe, dass Date::Calc immer noch nicht zur Standarddistribution gehört (auch nicht bei Perl 5.10), kam mir der Gedanke, dass einige Provider es u.U. nicht installiert haben (bei meinem ist es zwar installiert, aber wer weiß, wie's beim Nachbarn aussieht...).

Wie du gemerkt hast gibt es eine reine Perl Version, die sich überall einfach installieren läßt, wenn der Hoster sich weigert dieses zu installieren, wofür es aber keinen Grund gäbe, sondern das wäre eher Grund den Hoster zu wechseln. Wenn dieser Perl anbietet, sollte das installieren von CPAN Modulen zum Angebotsumfang gehören.

Und deswegen gibt's heute Nudeln und k***** ist erlaubt ;) Also her mit der Tomatensauce!

Was mir zuerst auffällt, du nennst das Modul Date::Today, das package aber nur Today, es müßte auch Date::Today heißen.
Als nächstes, warum definierst du die Variabeln mit our?
Dann brauchst du kein HASH für die Wochentag und Monatsnamen, da reichen einfach Arrays.
Das mit den Großbuchstaben ist zwar in Date::Calc auch so, es ist aber nicht die übliche Praxis. Ich verwende für Funktionen immer Kleinbuchstaben, Funktionen mit Großbuchstaben wären Konstruktorfunktionen, die man aber üblicherweise nicht braucht in Perl, sondern dort sind es die package Namen. Aber das sind nur Konventionen, die viele anders handhaben.

Und da du nicht mit Objekten arbeitest brauchst du die $today Parameter nie, d.h. du kannst sie wegschmeissen, entweder mit shift oder in dem du den wirklichen Parameter mit $_[1] abfragst.

Ich würde die Time Funktion z.b. so umsetzen:

sub xTime {  
  shift;  
  my $how = shift;  
  my $printf = !$how ? '%02d:%02d:%02d' :  
  $how eq 'short' ? '%02d:%02d' :  
  $how eq 'old' ? '%02d.%02d Uhr' : 'Fehler'  
  ;  
  return sprintf $printf, $lhour, $lmin, $lsec;  
}

Struppi.

[Patrick Andrieu]

Hallo Struppi!

Vielen Dank für Kritik und Ratschläge!

Wie du gemerkt hast gibt es eine reine Perl Version, die sich überall einfach installieren läßt, wenn der Hoster sich weigert dieses zu installieren, wofür es aber keinen Grund gäbe, sondern das wäre eher Grund den Hoster zu wechseln. Wenn dieser Perl anbietet, sollte das installieren von CPAN Modulen zum Angebotsumfang gehören.

Ich denke da (ganz langsam) an einer (eigentlich lange überfälligen) Neufassung des GBs. Von den Usern (viele haben nie etwas mit Perl gemacht) kann ich nicht verlangen, dass sie Module installieren o.Ä. Dieses kleine Modülche soll 'web-lib.pl' ersetzen, und soll einfach mit ins cgi-bin oder ugb-Ordner kopiert werden.

Wie gesagt, bei 1und1 ist Date::Calc [1] installiert, vielleicht ist es bei anderen Hostern nicht der Fall.

Was mir zuerst auffällt, du nennst das Modul Date::Today, das package aber nur Today, es müßte auch Date::Today heißen.

OK, danke. Wird geändert.

Als nächstes, warum definierst du die Variabeln mit our?

Die drei »our«-Variablen sollen von main erreichbar sein:

mit my $VERSION:

C:\Perl\site\lib\Date>perl -w

use strict;  
use Today;  
print $Today::VERSION;

^Z
Use of uninitialized value in print at - line 3.

mit our $VERSION:

C:\Perl\site\lib\Date>perl -w

use strict;  
use Today;  
print $Today::VERSION;

^Z
0.1

Wobei... die Elemente von localtime kann ich eigentlich »my-en«.

Dann brauchst du kein HASH für die Wochentag und Monatsnamen, da reichen einfach Arrays.

Sind Hashes denn so viel weniger performant? Ich arbeite gerne mit Hashes... ;) Aber da Cheatah die Internationalisation eingebracht hat, werde ich mir hier etwas Neues überlegen müssen.

Das mit den Großbuchstaben ist zwar in Date::Calc auch so, es ist aber nicht die übliche Praxis.

Bei Date::Calc sind die Methodennamen explizit, von daher stört die Großschreibung hier nicht, finde ich.

Ich verwende für Funktionen immer Kleinbuchstaben, Funktionen mit Großbuchstaben wären Konstruktorfunktionen, die man aber üblicherweise nicht braucht in Perl, sondern dort sind es die package Namen. Aber das sind nur Konventionen, die viele anders handhaben.

Ja. Nur hätte eine »sub time« mit »time()« geclashed. Ansonsten gebe ich Dir Recht, und ich werde »Time« in »now« umbenennen (und »Year« in »year«) - klingt auch besser:

my $time = $Date::Today::now();  
my $short_time = $Date::Today::now('short');  
my $old_german_with_single_dot_time = $Date::Today::now('old'); # ;)

Und da du nicht mit Objekten arbeitest brauchst du die $today Parameter nie, d.h. du kannst sie wegschmeissen, entweder mit shift oder in dem du den wirklichen Parameter mit $_[1] abfragst.

Die werden an wenigen Stellen gebraucht, wenn eine Funktion den Rückgabewert einer anderen benötigt, z.B. in »sub rfc«:

return $today->Year."-$month-$day";

sub xTime {

shift;
  my $how = shift;
  my $printf = !$how ? '%02d:%02d:%02d' :
  $how eq 'short' ? '%02d:%02d' :
  $how eq 'old' ? '%02d.%02d Uhr' : 'Fehler'
  ;
  return sprintf $printf, $lhour, $lmin, $lsec;
}

  
Schöner Code, aber meine private leading\_zero-Sub finde ich auch ganz nett ;)  
  
  
  
[1] Das sind übrigens alle Date::-Module, die installiert sind:  
Date::Calc  
Date::Calc::Object  
Date::Calendar  
Date::Calendar::Profiles  
Date::Calendar::Year  
Date::Format  
Date::Language  
Date::Language::Afar  
Date::Language::Amharic  
Date::Language::Austrian  
Date::Language::Brazilian  
Date::Language::Chinese\_GB  
Date::Language::Czech  
Date::Language::Danish  
Date::Language::Dutch  
Date::Language::English  
Date::Language::Finnish  
Date::Language::French  
Date::Language::Gedeo  
Date::Language::German  
Date::Language::Greek  
Date::Language::Italian  
Date::Language::Norwegian  
Date::Language::Oromo  
Date::Language::Sidama  
Date::Language::Somali  
Date::Language::Swedish  
Date::Language::Tigrinya  
Date::Language::TigrinyaEritrean  
Date::Language::TigrinyaEthiopian  
  
  
Viele Grüße aus Frankfurt/Main,  
Patrick

-- 
![](http://www.atomic-eggs.com/fuernA.jpg)  
  
\_ - jenseits vom delirium - \_  
  
[[link:hatehtehpehdoppelpunktslashslashwehwehwehpunktatomicminuseggspunktcomslash](http://www.atomic-eggs.com/)]  
Nichts ist unmöglich? [Doch!](http://www.atomic-eggs.com/cwi/cwi_4.shtml)  
Heute schon ge[gök](http://goek.atomic-eggs.com/goek_goek.html)t?

[Struppi]

Wobei... die Elemente von localtime kann ich eigentlich »my-en«.

Joh, die meinte ich eigentlich auch. $VERSION muss sogar global deklariert werden, damit use Modul VERSION; funktioniert.

Dann brauchst du kein HASH für die Wochentag und Monatsnamen, da reichen einfach Arrays.

Sind Hashes denn so viel weniger performant? Ich arbeite gerne mit Hashes... ;)

Absolut, dir muss klar sein, dass die Schlüssel immer Strings sind, die bei jeder Operation verglichen werden müssen und Stringvergleiche sind immer langsamer als Zahlenvergleiche.

Und da du nicht mit Objekten arbeitest brauchst du die $today Parameter nie, d.h. du kannst sie wegschmeissen, entweder mit shift oder in dem du den wirklichen Parameter mit $_[1] abfragst.

Die werden an wenigen Stellen gebraucht, wenn eine Funktion den Rückgabewert einer anderen benötigt, z.B. in »sub rfc«:

Schon klar, dass wenn du das Objekt brauchst, dass dann der Parameter Sinn macht, wenn nicht, dann nicht.

Schöner Code, aber meine private leading_zero-Sub finde ich auch ganz nett ;)

auch wenn das bei Zeitfunktionen nicht unbedingt eine Rolle spielt, hast du das mal "gebenchmarked"? Ich schon.

Aber du hast Recht eine private Fuunktion ist ganze nett ;-)
Übrigens du kannst diese Funktion auch so aufrufen:

$leading_zero->( ... );

Das Und-Zeichen sieht unschön, finde ich.

[1] Das sind übrigens alle Date::-Module, die installiert sind:

Das meiste davon sind ja untermodule von Date::Calc. du hast Date::Calc, Date::Calendar und Date::Format
(wobei ich den Sinn dieses Moduls nicht sehe, das kann POSIX alles schon)

Struppi.

[Patrick Andrieu]

Hallo Struppi!

Wobei... die Elemente von localtime kann ich eigentlich »my-en«.
Joh, die meinte ich eigentlich auch. $VERSION muss sogar global deklariert werden, damit use Modul VERSION; funktioniert.

Ich hätte ja von main auf Einzelelementen bei Bedarf zugreifen wollen, aber dafür habe ich »just_want« und %dt_parts, das ich außer 'noodles' mit Sinnvollerem füllen kann... ;)

Sind Hashes denn so viel weniger performant? Ich arbeite gerne mit Hashes... ;)

Absolut, dir muss klar sein, dass die Schlüssel immer Strings sind, die bei jeder Operation verglichen werden müssen und Stringvergleiche sind immer langsamer als Zahlenvergleiche.

Auch, wenn die Hash-Schlüssel, wie bei mir, Zahlen sind? Ich habe mich informiert und das hier gefunden: http://www.perlmonks.org/?node_id=630227. Im vorletzten Posting scheint die Hash-Iteration schneller zu sein.

Denn für die gewünschte Internationalisierung (falls ich sie je realisiere, denn sonst kann ich gleich Date::Calc/Pcalc einsetzen und spare mir die Arbeit), schwebt mir, im Gegensatz zur rein arraybasierten Lösung von Date::Pcalc, eher ein HoA vor. Dafür hätte ich zwei Varianten (am beispiel von %monthnames):

%monthnames = (
         0 => ["January", "Januar", "Janvier"],
         1 => ["February", "Februar", "Février"],
         ...
         };

mit dem Aufruf deutscher Monatsnamen in der Form $monthnames{$lmon}->[1], oder:

%monthnames = (
         0 => ["January", "February", "March", "April", ...],
         1 => ["Januar", "Februar", "März", "April", ...],
         ...
         };

mit dem Aufruf deutscher Monatsname: $monthnames{1}->[$lmon]...

Aber du hast Recht eine private Fuunktion ist ganze nett ;-)

Finde ich auch (habe ich von Siefreds Loganalyze.pm) ;)

Das Und-Zeichen sieht unschön, finde ich.

Unschön vielleicht, eine Unterscheidungshilfe ist es aber schon, finde ich.

----------------- Grundstazfragen zu Modulen -----------

Solele, diesen Bereich trenne ich etwas ab, ist er doch eher allgemeiner Natur.

1.) In Calc.pm (Date::Calc) steht folgende Zeile, was bedeutet sie?

bootstrap Date::Calc $VERSION;

2.) Spielt es in der Performance eine Rolle, wenn ich bereitgestellte
    Variablen oder Methoden mit qw/:all/ importiere, oder ist es in
    dieser Hinsicht besser, nur die Methoden zu importieren, die im
    aufrufenden Skript wirklich gebraucht werden? Denn so oder so,
    geladen wird das Modul eh komplett, sobald es mit use eingebunden
    ist - bei Date::Pcalc sind es inklusive Pod-Doku 3838 Zeilen (107KB).

Viele Grüße aus Frankfurt/Main,
Patrick

[Struppi]

Sind Hashes denn so viel weniger performant? Ich arbeite gerne mit Hashes... ;)
Absolut, dir muss klar sein, dass die Schlüssel immer Strings sind, die bei jeder Operation verglichen werden müssen und Stringvergleiche sind immer langsamer als Zahlenvergleiche.

Auch, wenn die Hash-Schlüssel, wie bei mir, Zahlen sind? Ich habe mich informiert und das hier gefunden: http://www.perlmonks.org/?node_id=630227. Im vorletzten Posting scheint die Hash-Iteration schneller zu sein.

Ja sie sind schneller, wenn du das Array nicht durchsuchen musst. Hier geht es ja um den Zugriff auf den Key bzw. auf den Index, da ist das Array vorzuziehen.

Denn für die gewünschte Internationalisierung (falls ich sie je realisiere, denn sonst kann ich gleich Date::Calc/Pcalc einsetzen und spare mir die Arbeit), schwebt mir, im Gegensatz zur rein arraybasierten Lösung von Date::Pcalc, eher ein HoA vor. Dafür hätte ich zwei Varianten (am beispiel von %monthnames):

%monthnames = (
         0 => ["January", "Januar", "Janvier"],
         1 => ["February", "Februar", "Février"],
         ...
         };

das ist was anderes und da würde ich dann auch lesbarere Keys verwenden.

in etwa so:

%monthnames = {  
de => [...],  
en => [...]  
};  

mit dem Aufruf deutscher Monatsnamen in der Form $monthnames{$lmon}->[1], oder:

$monthnames{$lang}->[$month];

Das Und-Zeichen sieht unschön, finde ich.

Unschön vielleicht, eine Unterscheidungshilfe ist es aber schon, finde ich.

Wenn dir das ->() nicht reicht?

----------------- Grundstazfragen zu Modulen -----------

Solele, diesen Bereich trenne ich etwas ab, ist er doch eher allgemeiner Natur.

1.) In Calc.pm (Date::Calc) steht folgende Zeile, was bedeutet sie?

bootstrap Date::Calc $VERSION;

Das gehört zu DynaLoader

2.) Spielt es in der Performance eine Rolle, wenn ich bereitgestellte
    Variablen oder Methoden mit qw/:all/ importiere, oder ist es in
    dieser Hinsicht besser, nur die Methoden zu importieren, die im
    aufrufenden Skript wirklich gebraucht werden? Denn so oder so,
    geladen wird das Modul eh komplett, sobald es mit use eingebunden
    ist - bei Date::Pcalc sind es inklusive Pod-Doku 3838 Zeilen (107KB).

Frag Hotte wie aufwendig die Datumsberechung ist, Date::Calc kann ja ein Haufen andere Sachen.

Wegen der Performance wird das keine grosse Rolle spielen, beim Exportieren geht es eher um die "Verschmutzung" des Namensraums, je mehr du exportierst umso größer wird die Chance das du mit deinen eigenen Variabeln in Konflikt kommst.

Struppi.

[Patrick Andrieu]

Hallo Struppi!

in etwa so:

%monthnames = {

de => [...],
en => [...]
};

> `$monthnames{$lang}->[$month];`{:.language-perl}  
  
Auch 'ne Idee. Ich werde eh nur 3 oder 4 Sprachen nehmen, User können den Hash dann selbst erweitern ;)  
  

> Wenn dir das ->() nicht reicht?  
  
Alles, wo ich meine Augen nicht anstrengen muss, um zu unterscheiden ob »{« oder »(«, ist mir lieber!  
  

> Frag Hotte wie aufwendig die Datumsberechung ist, Date::Calc kann ja ein Haufen andere Sachen.  
  
Ja, sieht man schon anhand der bereitgestellten Funktionen.  
  

>   
> Wegen der Performance wird das keine grosse Rolle spielen, beim Exportieren geht es eher um die "Verschmutzung" des Namensraums,  
  
Ah, jetzt hab' ich's. Thx!  
  
  
  
Viele Grüße aus Frankfurt/Main,  
Patrick

-- 
![](http://www.atomic-eggs.com/fuernA.jpg)  
  
\_ - jenseits vom delirium - \_  
  
[[link:hatehtehpehdoppelpunktslashslashwehwehwehpunktatomicminuseggspunktcomslash](http://www.atomic-eggs.com/)]  
Nichts ist unmöglich? [Doch!](http://www.atomic-eggs.com/cwi/cwi_4.shtml)  
Heute schon ge[gök](http://goek.atomic-eggs.com/goek_goek.html)t?

[Patrick Andrieu]

Re!

Internationalition jetzt ohne Probleme eingebaut.

Geändert habe ich den Parameteraufruf einiger Funktionen, dafür hat das Modul jetzt mehr davon. Auch wenn es etwas redundanter ist als in der ersten Fassung, wird es für einen User sicher einfacher zu bedienen, als sich 'nen Haufen Parameter zu merken.

Das Einzige, was noch mit Parameter aufgerufen werden muss, ist »new« bei der Instanzerzeugung, um die Sprache auszuwählen:

my $dto = Date::Today::new('de');

und bei »just_want«.

Freu mich wieder auf Kritik!

http://www.atomic-eggs.com/cgi-bin/date_today.pl

Viele Grüße aus Frankfurt/Main,
Patrick

[Beat]

und bei »just_want«.
Freu mich wieder auf Kritik!

dt_get->()

Mnemonik: Date Today und Get Methode.
Damit solltest möglichen du Konflikte im Namensraum hinreichend ausweichen.

mfg Beat

[Beat]

und bei »just_want«.
Freu mich wieder auf Kritik!

Hab's erst jetzt bemerkt
du verwendest ja gar keinen allgemeinen Getter mehr.

Ich hab mir da erst kürzlich was gesucht, wie man eigentlich eine Methodenpräambel übergeben könnte, das also alle Methoden mit einer vom User definierten Präfix aufrufen könnte. Bin aber noch nicht fündig geworden.

Die Meinung wäre in etwa:

my $date = Date::Today->new( 'dt_' ); # hier wird ein Präfix übergeben.

und dann der mögliche Aufruf:

$date->dt_set_language('dt');
$date->dt_get_year('dt');

Frage mich wie so was zu machen wäre.

mfg Beat

[Skrilax]

Hallo!

my $date = Date::Today->new( 'dt_' ); # hier wird ein Präfix übergeben.

und dann der mögliche Aufruf:

$date->dt_set_language('dt');
$date->dt_get_year('dt');

Frage mich wie so was zu machen wäre.

Solch ein Präfix ist doch aber nur sinnvoll, wenn die Funktionen in einen anderen Namensraum exportiert werden. In deinem Beispiel sind es Methodenaufrufe, bei denen keine Namenskonflikte auftreten sollten. Oder aus welchen Gründen brauchst du diese?

Als Klassen-/Objekt-Methoden kann sowas auf zwei Arten realisiert werden

• durch eine AUTOLOAD-Subroutine
• durch direktes manipulieren der Symboltabelle in der new-methode

Sollen die Funktionen mit Präfix exportiert werden, muss wohl eine eigene import-Routine geschrieben werden.

Grüße, Skrilax

[Beat]

Solch ein Präfix ist doch aber nur sinnvoll, wenn die Funktionen in einen anderen Namensraum exportiert werden. In deinem Beispiel sind es Methodenaufrufe, bei denen keine Namenskonflikte auftreten sollten. Oder aus welchen Gründen brauchst du diese?

Ich kann natürlich mit package Angaben Namensraum Konflikte umgehen, falls zwei Module gleiche Methodennamen verwenden.

Einen eigenen Exporter zu schreiben traue ich mir echt nicht zu.
So würde nur die Möglchkeit bleiben mit eval in der Konstruktorphase diese Methoden zu erzeugen. Das hat aber, so meine ich, eine empfindliche Performance Einbusse.
Naja, das scheint mir für das Namensraumproblem nicht angemessen.

Derzeit versuche ich, diese Lekture da zu verstehen.
http://www.perldesignpatterns.com/?PerlDesignPatterns

mfg Beat

[Struppi]

So würde nur die Möglchkeit bleiben mit eval in der Konstruktorphase diese Methoden zu erzeugen. Das hat aber, so meine ich, eine empfindliche Performance Einbusse.
Naja, das scheint mir für das Namensraumproblem nicht angemessen.

Sowas läßt sich mit der Technik, die z.b. in
Call::Accessor verwendet wird umsetzen.

#!/usr/bin/perl -w  
use strict;  
use constant NL => "\n";  
package Accessor;  
  
sub new {  
 my $proto = shift;  
 my $p = shift || 'x_';  
 my %dummy;  
  
 no strict 'refs';  
 foreach my $func (qw(a b c)) {  
        *{"${proto}::$p$func"}   = sub {  
   my $self = shift;  
   $dummy{$func} = $_[0] if @_;  
   return $dummy{$func};  
  };  
 }  
 my $self = bless \%dummy, $proto;  
  
}  
  
package main;  
  
my $y = new Accessor('y_');  
$y->y_a('y accessor');  
print $y->y_a(), NL;  
my $x = new Accessor('x_');  
$y->x_a('x accessor');  
print $y->x_a(), NL;  

Struppi.

[Struppi]

Call::Accessor

Class::Accessor

Jaja,es ist spät Nachts und ich wollte auch gar nichts mehr schreiben.

Struppi.

[Beat]

So würde nur die Möglichkeit bleiben mit eval in der Konstruktorphase diese Methoden zu erzeugen. Das hat aber, so meine ich, eine empfindliche Performance Einbusse.
Naja, das scheint mir für das Namensraumproblem nicht angemessen.

Sowas läßt sich mit der Technik, die z.b. in
Class::Accessor verwendet wird umsetzen.

Hallo Struppi

Ich habe deinen Code mal ausprobiert, und der funktioniert so auch.
Aber ich habe trotzdem Probleme, ihn ganz zu verstehen.

#!/usr/bin/perl -w  
use strict;  
use constant NL => "\n";  
package Accessor;  
  
sub new {  
  my $proto = shift;  
  my $p = shift || 'x_';               ## prefix nach Eingabe oder Default 'x_'  
  my %dummy;                           ## nicht wirklich nur dummy sondern DER DatenHash  
                                       ## oder ??  
  no strict 'refs';                    ## wegen typeglob  
  foreach my $func (qw(a b c)) {       ## in Schleife mehrere S/Getter setzen  
      *{"${proto}::$p$func"} = sub {   ## tricky. Subclassen  
       my $self = shift;               ## was'n das für n'Rest?  
                                       ## Klar, Objektreferenz hat keine Funktion mehr  
       $dummy{$func} = $_[0] if @_;    ## OK  
       return $dummy{$func};  
     };  
   }  
  my $self = bless \%dummy, $proto;  
  return $self;                        ## meine Kosmetik  
}  

Ich durchschaue es noch nicht ganz.
Aber wenn ich es richtig interpretiere, wird eigentlich
aus einer Klasse Subklassen abgeleitet.
Der Trick mit dem Typeglob bewirkt Eintrage der
anonymen Subfunktionen in die Symboltable,
'magisch' existiert also in der Symboltable ein
&{Accessor::x_a} (als Sub ansrechbar)
${Accessor::x_a} (als Referenz ansprechbar)

So kann also die Methode (hier die anonyme Subfunktion) in einer Referenz gespeichert werden, und denoch ist sie über den normalen Methoden zugriff mit dem -> Operator ansprechbar.

Einer Typeglob Version bin ich gestern bei der Lekture hier begegnet:
  http://www.perldesignpatterns.com/?AccessorPattern
  im oberen Abschnitt: "Writing Accessors is Tedious "

Das sieht insgesamt sehr elegant aus, vor allem, weil man von den Subclassen von aussen eigentlich nichts sieht.

my $y = new Accessor('y_');
$y->y_a('y accessor');
print $y->y_a(), "\n";

mfg Beat

[Struppi]

sub new {
  my $proto = shift;
  my $p = shift || 'x_';               ## prefix nach Eingabe oder Default 'x_'
  my %dummy;                           ## nicht wirklich nur dummy sondern DER DatenHash
                                       ## oder ??

Jaja, ich weiß jetzt auch nicht mehr warum ich das gestern eingebaut habe, egal.

no strict 'refs';                    ## wegen typeglob

genau.

*{"${proto}::$p$func"} = sub {   ## tricky. Subclassen
       my $self = shift;               ## was'n das für n'Rest?
                                       ## Klar, Objektreferenz hat keine Funktion mehr

Das ist eine anonyme Funktion oder ein closure.

my $self = bless %dummy, $proto;
  return $self;                        ## meine Kosmetik

eigentlich reicht ja auch return bless ..., ich mußte heut Nacht ein paar Sachen ausprobieren, weil ich (und Class::Accessor) diese Technik anders anwenden. Im Konstruktor Funktionen erzeugen ist mir nicht geheuer.

Aber wenn ich es richtig interpretiere, wird eigentlich
aus einer Klasse Subklassen abgeleitet.
Der Trick mit dem Typeglob bewirkt Eintrage der
anonymen Subfunktionen in die Symboltable,
'magisch' existiert also in der Symboltable ein
&{Accessor::x_a} (als Sub ansrechbar)
${Accessor::x_a} (als Referenz ansprechbar)

Ich muss leider sagen, selbst als fortgeschrittener Laie tue ich mich schwer solche Dinge zu erklären. Ich habe lange gebraucht und viel rumprobiert, bis ich das so einsetzen konnte wie ich wollte, aber soweit ich das verstanden dürfte deine Beschreibung zutreffen.

So kann also die Methode (hier die anonyme Subfunktion) in einer Referenz gespeichert werden, ...

Nicht in einer Referenz, sondern in _der_. Der Nachteil dieser Methode ist, dass du bei jedem Objekt neue Funktionen in dem Package anlegst, d.h. in meinem Beispiel hat das y_ Objekt auch die Funktionen des x_ Objektes, da die Methoden im Namnensraum Accessor:: angelegt werden.

Ob und wie es geht, nur einem Objekt diese Funktion zu zuweisen, weiß ich nicht. In JS ist das einfach und ich denke auch dass es in Perl geht, nur wie?

Einer Typeglob Version bin ich gestern bei der Lekture hier begegnet:
  http://www.perldesignpatterns.com/?AccessorPattern
  im oberen Abschnitt: "Writing Accessors is Tedious "

JaJa, das ist die Technik, wie gesagt Class::Accessor benutzt diese (es gibt auch noch eine fast und faster Version davon).

Struppi.

[Beat]

Hallo Struppi
Das Script ist wohl doch nicht sehr nützlich.
Der untenstehende Test verdeutlicht es.

  
#!usr/bin/perl -w  
#  
use strict;  
use CGI::Carp qw(fatalsToBrowser);  
  
BEGIN {  
 use CGI::Carp qw(carpout);  
 open(LOG, ">>error.txt")  or  die "Unable to append to error.txt: $!\n";  
 carpout(*LOG);  
}  
  
  
  
use constant NL => "\n";  
  
package Accessor;  
  
  
sub new {  
  my $proto = shift;  
  my $p = shift || 'x_';  
  my %dummy;  
  no strict 'refs';  
  foreach my $func (qw(a b c)) {  
         *{"${proto}::$p$func"}   = sub {  
       my $self = shift;                  ## sic!  
       $dummy{$func} = $_[0] if @_;  
       return $dummy{$func};  
     };  
   }  
  my $self = bless \%dummy, $proto;  
  return $self;  
}  
  
  
  
  
package main;  
  
# TEST  
  
print NL;  
my $y = new Accessor('y_');  
$y->y_a('$y, y_');  
print '$y->y_a() : ', $y->y_a(), NL;  
  
print NL;  
my $x = new Accessor('x_');  
$x->x_a('$x, x_');  
print '$y->x_a() : ', $y->x_a(), NL;  
print '$y->y_a() : ', $y->y_a(), NL;  
print '$x->x_a() : ', $x->x_a(), NL;  
print '$x->y_a() : ', $x->y_a(), NL;  
  
print NL;  
my $z = new Accessor('z_');  
$z->z_a('$z, z_');  
print '$z->x_a() : ', $z->x_a(), NL;  
print '$z->y_a() : ', $z->y_a(), NL;  
print '$z->z_a() : ', $z->z_a(), NL;  
  
sleep(20);  
  
exit;  
__END__  

Die Instanz $z hat vollen Zugriff auf die Eigenschaften von Instanzen $x und $y.

mfg Beat

[Struppi]

Die Instanz $z hat vollen Zugriff auf die Eigenschaften von Instanzen $x und $y.

Das ist das was ich bereits gesagt habe.

Der Nachteil dieser Methode ist, dass du bei jedem Objekt neue Funktionen in dem Package anlegst, d.h. in meinem Beispiel hat das y_ Objekt auch die Funktionen des x_ Objektes, da die Methoden im Namnensraum Accessor:: angelegt werden.

Ich weiß auch nicht wie man das mit Perl anders macht, ich selber nutze die Technik auch nicht so.

Struppi.

[Beat]

eine kleine Modifikation:

  
package Accessor;  
  
  
sub new {  
  my $proto = shift;  
  my $p = shift || 'x_';  
  my %dummy;  
  no strict 'refs';  
  foreach my $func (qw(a b c)) {  
         *{"${proto}::$p$func"}   = sub {  
       my $self = shift;  
       $dummy{$self}{$func} = $_[0] if @_;  ## Hier  
       return $dummy{$self}{$func};         ## Hier  
     };  
   }  
  my $self = bless \%dummy, $proto;  
  return $self;  
}  

mfg Beat

[Struppi]

$dummy{$self}{$func} = $_[0] if @_;  ## Hier
       return $dummy{$self}{$func};         ## Hier

Das ist Unsinn, %dummy ist das gleiche wie $self, d.h. du nimmst hier eine Referenz auf sich selbst als schlüssel.

Struppi.

[Siechfred]

Das ist Unsinn, %dummy ist das gleiche wie $self, d.h. du nimmst hier eine Referenz auf sich selbst als schlüssel.

Nur mal so am Rande, wozu soll das Ganze mit x_a, y_a usw. gut sein, wenn das Ergebnis doch immer das Gleiche ist? Ein konkreter Anwendungsfall würde da meinem Verständnis auf die Sprünge helfen :)

Siechfred

[Struppi]

soll das Ganze mit x_a, y_a usw. gut sein, wenn das Ergebnis doch immer das Gleiche ist? Ein konkreter Anwendungsfall würde da meinem Verständnis auf die Sprünge helfen :)

Beat hat es hier beschrieben. Im Prinzip will zur Laufzeit der Instanz Methoden zufügen. Das macht aber mein Vorschlag nicht, dieser fügt dem package Methoden zu.

Ein konkreter Anwendungsfall ist, wie gesagt, Class::Accessor, einer "Klasse" zur Laufzeit Zugriffsfunktionen hinzufügen.

Struppi.

[Siechfred]

Beat hat es hier beschrieben. Im Prinzip will zur Laufzeit der Instanz Methoden zufügen. Das macht aber mein Vorschlag nicht, dieser fügt dem package Methoden zu.

Habe ich gelesen, aber wozu sollte man das machen wollen?

Siechfred

[Beat]

Das ist Unsinn, %dummy ist das gleiche wie $self, d.h. du nimmst hier eine Referenz auf sich selbst als schlüssel.

Unsinnig sieht es aus.
Aber jetzt sind die Daten einer Instanz vor Manipulationen durch eine andere Instanz geschützt.

mfg Beat

[Struppi]

Aber jetzt sind die Daten einer Instanz vor Manipulationen durch eine andere Instanz geschützt.

Das lag nur an dem unnötigen %dummy Hash, ohne geht es auch:

sub new {  
 my $proto = shift;  
 my $p = shift || 'x_';  
  
 no strict 'refs';  
 foreach my $func (qw(a b c)) {  
        *{"${proto}::$p$func"}   = sub {  
   my $self = shift;  
   $self->{$func} = $_[0] if @_;  
   return $self->{$func};  
  };  
 }  
 return bless {}, $proto;  
}  

Struppi.

[Patrick Andrieu]

Hallo Beat!

und bei »just_want«.
dt_get->()

Ach mal gucke... Bei File::Find wird bei den Beispielen eine sub »wanted« vorgeschlagen, das war quasi Pate für die Namensgebung. Außerdem kann der User damit spielen:

my $today_I = new Date::Today;
...
$today_I->just_want('...'); :)

Viele Grüße aus Frankfurt/Main,
Patrick

[Christoph]

Moin.

Kleine Anmerkung: Ich würde die Bezeichnung iso_date() gegenüber rfc_date() bevorzugen. Zumindest mir ist die erste Bezeichnung geläufiger...

Christoph

[Patrick Andrieu]

Hallo Christoph!

iso_date() gegenüber rfc_date() bevorzugen.

Werde ich ändern, Danke. iso8601_date() <- ist noch sprechender.

Viele Grüße aus Frankfurt/Main,
Patrick

[Christoph]

Moin.

iso_date() gegenüber rfc_date() bevorzugen.

Werde ich ändern, Danke. iso8601_date() <- ist noch sprechender.

Aber auch länger und weniger gut zu merken.

Christoph

[Patrick Andrieu]

Hallo Christoph!

Aber auch länger und weniger gut zu merken.

Mag sein. Aber wenn Du Dir die Namensgebung von Date::Calc ansiehst, ist diese an Länge nur durch meine übertroffen ;)

Viele Grüße aus Frankfurt/Main,
Patrick

[Siechfred]

Freu mich wieder auf Kritik!

Wie wäre es noch mit dem IETF-Format (z.B. für <lastBuildDate>-Elemente in Feeds)?

Siechfred

[Patrick Andrieu]

Hallo Siechfred!

Wie wäre es noch mit dem IETF-Format (z.B. für <lastBuildDate>-Elemente in Feeds)?

Meinst Du hier den vollen Date-/Timestamp nach Dublin Core? Also sowas wie:

2008-06-12T08:40+02:00?

Hm, das muss aber GMT sein, oder? Sönst könnte sich die User den Timestamp selbst konstruieren, wobei... was ist bei Uhrzeit < 2 (oder < 1 Winter)? Nehmen wir an, localtime spuckt:

2008-06-12T01:30:00

aus, müsste der Timestamp dann sein:

2008-06-11T23:30:00+02:00?

Was ich auch immer fragen wollte... Was bedeutet die Zahl in Klammern bei der Nennung von Funkionen in den Dokumentationen (perldoc und Modul-PODs):

This scalar value is not locale dependent but is a Perl builtin.
  For GMT instead of local time use the "gmtime" builtin. See also
  the "Time::Local" module (to convert the second, minutes, hours,
  ... back to the integer value returned by time()), and the POSIX
  module's strftime(3) and mktime(3) functions.
                    ^             ^

Viele Grüße aus Frankfurt/Main,
Patrick

[Patrick Andrieu]

Re!

2008-06-12T01:30:00

aus, müsste der Timestamp dann sein:

2008-06-11T23:30:00+02:00?

Oder bedeutet:

2008-06-12T09:00+02:00

bereits, dass es GMT-mäßig 7 Uhr ist? RFCs lesen macht mich selten schlauer, das überlasse ich RFC-Gunnar ;)

Viele Grüße aus Frankfurt/Main,
Patrick

[Tim Tepaße]

Hallo,

2008-06-12T09:00+02:00
bereits, dass es GMT-mäßig 7 Uhr ist?

Ja.

Tim

[Harlequin]

Yerf!

... back to the integer value returned by time()), and the POSIX
  module's strftime(3) and mktime(3) functions.

Hm, die Schreibweise kenn ich von den Manpages um den Abschnitt anzugeben, wo man die Inforamtionen dazu findet.

Dementsprechend sollte ein "man 3 strftime" ein Ergebnis liefern.

Gruß,

Harlequin

[Tim Tepaße]

Hallo,

Wie wäre es noch mit dem IETF-Format (z.B. für <lastBuildDate>-Elemente in Feeds)?
Meinst Du hier den vollen Date-/Timestamp nach Dublin Core? Also sowas wie:

Streng genommen meint er im RSS-Zusammenhang Datumsangaben nach RFC 822, wobei das im Kontext von RSS 2.0 noch durch vierstellige Jahreszahlen ergänzt wurde.

<lastBuildDate>Mon, 15 Oct 2007 09:10:00 EST</lastBuildDate> wird im RSS 2.0 Profil empfohlen.

2008-06-12T08:40+02:00?

Das ist ISO 8601 oder das neuere IETF-Format nach RFC 3339, das z.B. in Atom verwendet wird.

Hm, das muss aber GMT sein, oder? Sönst könnte sich die User den Timestamp selbst konstruieren, wobei... was ist bei Uhrzeit < 2 (oder < 1 Winter)? Nehmen wir an, localtime spuckt:
  2008-06-12T01:30:00
aus, müsste der Timestamp dann sein:
  2008-06-11T23:30:00+02:00?

Nach dem Plus steht immer der Unterschied zu UTC/GMT. +2 ist also Sommerzeit, +1 Winterzeit. Also, ja, derzeit ja.

module's strftime(3) and mktime(3) functions.

http://de.wikipedia.org/wiki/Manpage#Aufbau. (Ich finde das auch absurd)

Tim

[Patrick Andrieu]

Hallo Tim und Siechfred!

Streng genommen meint er im RSS-Zusammenhang Datumsangaben nach RFC 822, wobei das im Kontext von RSS 2.0 noch durch vierstellige Jahreszahlen ergänzt wurde.
<lastBuildDate>Mon, 15 Oct 2007 09:10:00 EST</lastBuildDate> wird im RSS 2.0 Profil empfohlen.

Was bedeutet »EST« (Time Zone-Angabe) und gibt es weitere?

Ich habe eben eine iso8601_tstamp-Methode eingebaut, sie liefert einen kompletten time stamp nach DC:

2008-06-12T12:58:15+02:00

Obiges ist auch kein Problem (für die Abkürzungen gibt's 'ne neue private Sub - ich liebe sie, ja...). Nur hier wird nur das Datum vermerkt. Sind die anderen Angaben wichtig (Uhrzeit, EST) bzw. vorgeschrieben oder Norm?

Am Besten wäre einfach nur eine neue Methode (vielleicht IETF_date genannt) nur für diese Ausgabeform (also: Thu, 12 Jun 2008)... ein Modul-User kann sich dann den Rest zusammenbauen:

my $lastBuildDate = $t->date." ".$t->now." whatever";

module's strftime(3) and mktime(3) functions.

http://de.wikipedia.org/wiki/Manpage#Aufbau. (Ich finde das auch absurd)

Danke (auch an Harlequin) hier auch!

Viele Grüße aus Frankfurt/Main,
Patrick

[at]

Hallo.

Was bedeutet »EST« (Time Zone-Angabe) und gibt es weitere?

Du machst dir all die Mühe, ohne zumindest für die Grundlagen einen Blick in die Wikipedia zu werfen?
MfG, at

[Patrick Andrieu]

Hallo at!

Du machst dir all die Mühe, ohne zumindest für die Grundlagen einen Blick in die Wikipedia zu werfen?

Ach, Mühe ist es keine. Und (Perl) lernen tu ich auch noch dabei, von der Kritik aber auch von solchen interessanten Drifts wie der Diskussion zw. Beat und Struppi.

Den DC-Time-Stamp kannte ich vom Aufbau her, ansonsten gebe ich Dir Recht, ich habe mich mit »Zeitgemäßem« wenig beschäftigt bisher. Natürlich habe ich Wikipedia bemüht, und die Übersetzung von »Sommerzeit/Winterzeit« war etwas mühsam. Dabei war »Sommerzeit« schnell in allen Sprachen übersetzt, da brauchte ich nur die entsprechende Wikipedia-Seite in der gewünschten Sprache anzuklicken... allerdings nicht alle erwähnten den Begriff »Winterzeit«, und so habe ich das italienische, beinahe teuflisch klingende »ora invernale« anderswo gefunden (glaube ich zumindest)...

Die Methode IETF_date ist eingebaut.

Viele Grüße aus Frankfurt/Main,
Patrick

[at]

Hallo.

Ach, Mühe ist es keine. Und (Perl) lernen tu ich auch noch dabei, von der Kritik aber auch von solchen interessanten Drifts wie der Diskussion zw. Beat und Struppi.

Von Programmierung verstehe ich nichts, ich bin nicht turing-vollständig.

Den DC-Time-Stamp kannte ich vom Aufbau her, ansonsten gebe ich Dir Recht, ich habe mich mit »Zeitgemäßem« wenig beschäftigt bisher. Natürlich habe ich Wikipedia bemüht, und die Übersetzung von »Sommerzeit/Winterzeit« war etwas mühsam. Dabei war »Sommerzeit« schnell in allen Sprachen übersetzt, da brauchte ich nur die entsprechende Wikipedia-Seite in der gewünschten Sprache anzuklicken... allerdings nicht alle erwähnten den Begriff »Winterzeit«, und so habe ich das italienische, beinahe teuflisch klingende »ora invernale« anderswo gefunden (glaube ich zumindest)...

Ich hatte mich nur gewundert, weil es auch für einen Laien wie mich so leicht unter "Zeitzonen" zu finden war, während du dich ganz offensichtlich am einen oder anderen wenig zielführenden Detail festgebissen hattest.

Die Methode IETF_date ist eingebaut.

Ich gratuliere dir herzlich und freue mich für jeden, der etwas damit anfangen kann. Ich persönlich bin da auf absehbare Zeit außen vor.
MfG, at

[Tim Tepaße]

Hallo Patrick,

Was bedeutet »EST« (Time Zone-Angabe) und gibt es weitere?

Ja, wie Du durch RFC-Lesen hättest herausfinden können. Der eigentlich für E-Mails zuständige RFC 822 spezifiziert die Zeitzonen "UT" und "GMT" für die UTC-Zeit, "EST", "EDT","CST", "CDT", "MST", "MDT", "PST", "PDT" für die vier kontinentalamerikanischen Zeitzonen bzw. der Tageslicht-Varianten, ein absurdes militärisches System in dem sehr absurd die Zeitzonen nicht kontinuierlich mit den Buchstaben A bis I und K bis Z benannt werden und die vernünftigste Variante, "+0200" wie auch anderswo genutzt. Es gibt also mehrere Varianten, eine Zeitzone zu benutzen, mal davon abgesehen, dass man immer umrechnen kann.

Ich würde die benannten Zeitzonen weglassen, insbesondere das absurde militärische Einbuchstabensystem wurde offenbar falsch beschrieben; von diesem wird im Update RFC 2822 dringend davon abgeraten. Nebenbei wird für die RSS-Feeds wird im RSS Profil sogar empfohlen nur UTC-Zeit zu benutzen.

Ich habe eben eine iso8601_tstamp-Methode eingebaut, sie liefert einen kompletten time stamp nach DC:

Kurzes Wort zur Terminologie: ISO 8601 spezifiziert diverse Zeitstempel und Zeitabschnitte. Alle Möglichkeiten von des ISO Standards nutzt kaum jemand, stattdessen werden Profile davon gebasteln, das W3C hat NOTE-datetime und in XML Schema Datentypen ich glaube wieder etwas eigenes, IETF hat RFC 3339. Die Unterschiede zwischen denen sind minimalst aber dennoch vorhanden.

Dublin Core orientiert sich explizit am W3C-Profil. Zu sagen, diese Zeitstempel wären nach DC, ist etwas mißleitend, vor allem weil DC eher unbekannt ist.

Nur hier wird nur das Datum vermerkt.

»Da« ist keine besonders tolle Quelle für RSS-Wissen und genau das machen sie auch noch falsch. Der 822-Zeitstempel wird übrigens nicht nur in Feeds, sondern auch in E-Mails benutzt. Und neu definiert in HTTP. Das sind nur Anwendunungen davon. ;)

Sind die anderen Angaben wichtig (Uhrzeit, EST) bzw. vorgeschrieben oder Norm?

Läsest Du den RFC, würdest Du herausfinden, dass beim RFC-(2)822-Zeitstempel alles vorgeschrieben ist, so bleibst Du leider im Düstern. ;)

Am Besten wäre einfach nur eine neue Methode (vielleicht IETF_date genannt)

Das IETF hat inzwischen mit RFC 3339 erkannt, dass der ISO-Zeitstempel dem RFC-(2)822-Zeitstempel wahnsinnig überlegen ist und will den nur noch in Zukunft benutzen. IETF_date wäre also streng genommen eine nicht so tolle Bezeichnung.

Tim

[Patrick Andrieu]

Hallo Tim!

Erstmal vielen lieben Dank für die Geduld ;)

Ja, wie Du durch RFC-Lesen hättest herausfinden können.

Diese Dingens bereiten mir Kofpschmerzen... Und ja, ich verhalte mich da wie ein Forumsnewbie, der drauf pocht, dass jemand bereits diese Texte gelesen - und vor allem verstanden und verinnerlicht hat. Dieses jemand bist heute Du ;)

Der eigentlich für E-Mails zuständige RFC 822 spezifiziert die Zeitzonen "UT" und "GMT" für die UTC-Zeit, "EST", "EDT","CST", "CDT", "MST", "MDT", "PST", "PDT" für die vier kontinentalamerikanischen Zeitzonen bzw. der Tageslicht-Varianten, ein absurdes militärisches System in dem sehr absurd die Zeitzonen nicht kontinuierlich mit den Buchstaben A bis I und K bis Z benannt werden und die vernünftigste Variante, "+0200" wie auch anderswo genutzt. Es gibt also mehrere Varianten, eine Zeitzone zu benutzen, mal davon abgesehen, dass man immer umrechnen kann.

Da greifst Du ein Thema auf... Das ist das, was mich am meisten ärgert. Überall gibt es Normen, die _gelten_ (Industrie, Autoindustrie, etc...), an die Hersteller sich halten _müssen_ - sonst... Lizenzentzug ö.ä. Strafen. In der Computerei (hier als Oberbegriff für alles, was damit zu tun hat), ist alles erlaubt. Niemand kontrolliert wirklich, jeder kann machen, was er will und das W3C brüllt in Webangelegenheiten auch nur gegen die Wand... Das alles hat mich - ist lange her, ich suche im Archiv nicht mehr danach -, zu einer Aussage in einer Antwort an Roland Blühtgen (älteren »Hasen« vielleicht besser bekannt als »Calocybe«) gebracht, die in etwa wie: »unsausgereifte Kindereien« lautete.

Es gibt immer noch keine zwingende Normen für kommerzielle Webseiten, es gibt keine zwingende Normen für Anwendung-Interfaces... mag hart klingeln, aber angesichts des ganzen Mülls, was einem »dadraußen« begegnet, wünsche ich mir sie, diese Normen. Nichts gegen Vielfalt und Kreativität, aber alles machen, nur weil es möglich ist, führt zwangsläufig zum pluralen Chaos...

OK, ich beruhige mich schon wieder, also zurück zum Thema.

Ich schreibe nur ein kleines Progrämmche, was Strings aus Elementen, die ich aus localtime() hole, ausgeben soll, damit ich (vor allem) und evtl. User des Moduls (hoffe ich) nicht das jedesmal selber müssen. Nur weiß ich trotz (oder wegen) der vielen Links, die Du mir gegeben hast, immer noch nicht, was ich dadrin anbieten soll.

Ich will nämlich nur das Angebot stellen, und - solange es keine verlässlichen Normen gibt - dem User überlassen, welchen String er haben will. Wenn er, wie in der von mir verlinkten Seite, nur:

Thu, 12 June 2008

haben will... sein Bier. Wenn er lieber den Zeitstempel:

2008-06-12T21:55:00+02:00

mag... auch egal. Wenn er:

Thu, 12 June 2008 23:59:59 EST

für seine Zwecke braucht, soll er sich das auf einfache Weise zusammenbauen können - die Beispiele liefere ich.

Nur, wie soll/kann ich wissen, was wirklich richtig ist?

IETF_date wäre also streng genommen eine nicht so tolle Bezeichnung.

Langsam geht mir die Fantasie aber aus ;) Aber OK, ich überlege mir etwas anderes...

Viele Grüße aus Frankfurt/Main,
Patrick

[Patrick Andrieu]

Hallo Tim!

Nach Deinen Einwänden habe ich einige Methoden umbenannt, mich dabei an Date::Calc orientiert (bis auf die Großschreibung). Sollte das Modülche das Date::-Set ergänzen, fühlen sich evtl. User so etwas wie »daheim« ;)

Die zurückgegebenen Werte der »iso«-Methoden und der in »date_to_text_en« umbenannten »IETF_date«-Methode habe ich nicht geändert, wer etwas anderes braucht, kann sich anhand anderen Methoden einen eigenen String zusammenbauen. »just_want« habe ich diesbezüglich auch erweitert.

Ach und ich eine POD verfasst, die auch nach Kritik verlangt, da mein English ja bekannterweise nicht der Beste ist. Soll kein Oxford English sein (das ist ja kaum eine POD), aber es sollte keiner, der gut English spricht, vor Lachen 'nen Infarkt kriegen, weil ich vielleicht irgendwelche dicke Patzer oder einfach nur komisch klingende Erläuterungen eingebaut habe ;)

Danke an alle für die Lesemühe hierfür!

http://www.atomic-eggs.com/cgi-bin/date_today.pl

Viele Grüße aus Frankfurt/Main,
Patrick

[Christoph]

Moin.

Ich hab mal deine POD (wirklich nur kurz) überflogen. Hier, was ich anders machen würde (bin aber auch kein 'native speaker'):

elaborated --> more complex/intricate
different formatted --> differently formatted
something other --> something else
same like --> same as
insteed --> instead
having copy --> having copied
doing following --> doing the following
in usage in --> in use by

Christoph

[Patrick Andrieu]

Hallo Christoph!

Ich hab mal deine POD (wirklich nur kurz) überflogen. Hier, was ich anders machen würde (bin aber auch kein 'native speaker')

Danke für die Mühe [1]. Korrigiert habe ich:

[x] different formatted --> differently formatted
[x] something other --> something else
[x] same like --> same as
[x] insteed --> instead
[x] having copy --> having copied
[x] doing following --> doing the following
[x] in usage in --> in use by

[x] proceding --> proceeding (eben noch selbst bemerkt)

aber nicht:

elaborated --> more complex/intricate

sondern:

[x] elaborated --> elaborate

! Denn »elaborate« ist ja synonym für eben »highly complex, intricate«. Gerade in Dokus kommt der Ausdruck »for more elaborate ...« öfters vor.

[1] eine POD nicht auf der Konsole zu lesen ist schon mühsam... seltsames Format, dieses ;)

Viele Grüße aus Frankfurt/Main,
Patrick

[Patrick Andrieu]

...bevor der Thread verschwindet... ;)

Und wie oft: Ein Beitrag, zwei Anliegen!

1. Das Modul wurde etwas geändert, unsinnige Methode 'raus, neue 'rein, etc. Jetzt möchte ich die erfahreneren Perler wie Siechfred, Struppi, Alexander uem hier um Code-Kritik bitten (wenn ich schon dabei bin, viel zu lernen, dann richtig)!

Was sieht seltsam aus, was läßt sich verkürzen, ohne unwartbar zu werden?

Zwischenstand: http://www.atomic-eggs.com/cgi-bin/date_today2.pl

2. Nach welchen Regeln wird die aktuelle Woche des Jahres festgelegt? Ich stelle eben fest, dass Date::Calc wohl falsch ansetzt, denn:

C:>perl -w

use Date::Calc qw/:all/;  
$t = Week_of_Year(Today);  
print $t;

^Z
25
C:>perl -w

use Date::Calc qw/:all/;  
$t = Week_Number(Today);  
print $t;

^Z
25

Sowohl »Week_of_Year« als »Week_Number« liefern 25 zurück, obwohl wir laut meinem Kalender die 24. Woche haben.

Also... wie viele Tage muss die letzte Woche eines Jahres haben, um als 53. Woche zu zählen, bzw. anders rum, wie viele Tage vor dem ersten Montag muss es geben, damit die diese Tagen als 1. Woche eines neuen Jahres zählen? Kurzum: wie lautet die Regel?

Viele Grüße aus Frankfurt/Main,
Patrick

[Patrick Andrieu]

Aargh!

Sowohl »Week_of_Year« als »Week_Number« liefern 25 zurück, obwohl wir laut meinem Kalender die 24. Woche haben.

Ich habe wohl vor lauter (und lautem) Gehupe gestern den Wochenwechsel verpaßt. Grund für Frage 2 ist nicht gegeben (kein seltsames Verhalten von Date::Calc), die Regel wüßte ich trotzdem gerne ;)

Viele Grüße aus Frankfurt/Main,
Patrick

[at]

Hallo.

Grund für Frage 2 ist nicht gegeben (kein seltsames Verhalten von Date::Calc), die Regel wüßte ich trotzdem gerne ;)

Nachschlagen!
MfG, at

[Patrick Andrieu]

Hallo at!

Nachschlagen!

Grmph... auf dem Begriff »Kalenderwoche« war ich nicht gekommen... Thanks!

Viele Grüße aus Frankfurt/Main,
Patrick

[Patrick Andrieu]

Re!

1. Das Modul wurde etwas geändert, unsinnige Methode 'raus, neue 'rein, etc. Jetzt möchte ich die erfahreneren Perler wie Siechfred, Struppi, Alexander uem hier um Code-Kritik bitten (wenn ich schon dabei bin, viel zu lernen, dann richtig)!

Hm, wenn sich keiner meldet, gibt es nur zwei Möglichkeiten:

1. Der Code ist soweit i.O., dass er nur noch Kosemtik braucht, oder:

2. Er ist total Sch...rott, und deswegen meldet sich niemand.

Übrigens: Mit beiden Anworten kann ich leben, mit 2., wenn mit Tipps gespickt, wahrscheinlich sogar mehr als mit 1..

Viele Grüße aus Frankfurt/Main,
Patrick

[Beat]

Hm, wenn sich keiner meldet, gibt es nur zwei Möglichkeiten:

1. Der Code ist soweit i.O., dass er nur noch Kosemtik braucht, oder:
2. Er ist total Sch...rott, und deswegen meldet sich niemand.
   Übrigens: Mit beiden Anworten kann ich leben, mit 2., wenn mit Tipps gespickt, wahrscheinlich sogar mehr als mit 1..

Hallo Patrick

Ein typisches Problem bei deinem Script.

Du sagst:
my $dst = $today_de->just_want('dst');

Das ist kontraproduktiv
in $dst ist nicht TRUE oder FALSE vorhanden, sondern der Wert ist immer True, nämlich 'Sommerzeit' oder 'Winterzeit'
Es würde vollauf genügen, wenn $today_de->just_want('dst') True oder False zurückgibt;

$today_de->just_want('dst') and
    print $today_de->full_year, " ist Sommerzeit";

oder du spendierst ein
$today_de->just_want('is_dst')
und
$today_de->just_want('dst_name')

Leider bleibt auch so der mehrsprachige Today Formatierer wenig praktisch.
Ich kann ihm nicht mal einen anderen Zeitstring zuführen.

mfg Beat

[Patrick Andrieu]

Hallo Beat!

oder du spendierst ein
$today_de->just_want('is_dst')
und
$today_de->just_want('dst_name')

Genau das habe ich jetzt gemacht. Denn Du hast recht, manchmal reicht es vielleicht, zu wissen, ob DST ist - ohne gleich das »Sommerzeit« oder »heure d'été« ausgegeben wird.

Leider bleibt auch so der mehrsprachige Today Formatierer wenig praktisch.
Ich kann ihm nicht mal einen anderen Zeitstring zuführen.

^Hier verstehe ich nicht, was Du meinst.

--------

Heute habe ich eine sub eingebaut, die, nebst anderen Sachen, die Woche des Jahres (nach ISO8601) zurückgibt. Nur: elegant ist was anderes. Allerdings kann ich es nicht so cool wie bei Date::Calc lösen, denn dort ruft die sub »Week_of_Year« andere Subs auf für die Berechnungen, die ich nicht habe. Nun ja, jedenfalls stimmt der zurückgegebene Wert, getestet von 2006-2019, jeweils testweise Januar (erste Wochen), Dezember (letzte Wochen) und auch mal Jahresmitte zur Kontrolle - nachdem meine allererste sub Murks lieferte ;)

Viele Grüße aus Frankfurt/Main,
Patrick

[Beat]

Leider bleibt auch so der mehrsprachige Today Formatierer wenig praktisch.
Ich kann ihm nicht mal einen anderen Zeitstring zuführen.

^Hier verstehe ich nicht, was Du meinst.

my $time = '47239547';
my $time = 'de';
use Today;
my $timeObj = Today->new( {time=> $time, language =>$lang} );

Ich würde nicht im Setzen der Sprache das Wichtigeste sehen, sondern in der Übergabe einer Time (in Sekunden).
Damits kein Chaos gibt:
Übergabe im Konstruktor mit anonymem Hash,

Damit hast du dein Modul erweitert zu einem allgemeinen TimeFormatter

Datumsvergleich spielt meiner Ansicht nach eine grössere Priorität, denn reine Fomattierkunst.
Voraussetzung ist, dass dein Modul mit vom User spendierten Sekundenangaben umgehen kann.

Grüsse aus einem Berg von Rechtschreibkorrekturen, die mir meine Lektotrin gerade um die Ohren geworfen hat.
Beat

[Patrick Andrieu]

Hallo Beat!

my $time = '47239547';

Wenn Du den UNIX-Timetamp meinst, der ist derzeit 10stellig. Und wann wurde die Milliarde erreicht? Wann die Zweite? ;)

my $time = 'de';
use Today;
my $timeObj = Today->new( {time=> $time, language =>$lang} );

Aber jetzt verstehe ich, was Du im Vorposting meintest, nur will ich ja nicht Date::Calc nachprogrammieren. Ich wollte nur Strings aus dem aktuellen Datum (»Today's Date«), dann kam das mit den Sprachen dazu...  ;)

Datumsvergleich spielt meiner Ansicht nach eine grössere Priorität, denn reine Fomattierkunst.

Aber ich lasse mir das durch den Kopf gehen. Für Today (.pm) ist erst mal Ruhe, man will sich ja auch anderen Sachen widmen.

Danke für Deinem Antworten in einem so alten Thread!

Viele Grüße aus Frankfurt/Main,
Patrick