Opened by paidopoieo at 2006-07-28 01:13
User since
2003-08-04
2145 Artikel
ModeratorIn + EditorIn
2003-08-04
2145 Artikel
ModeratorIn + EditorIn
Wenn ich ausprobieren und verstehen möchte, wie man CSV-Dateien verarbeitet, dann programmiere ich mir die Routinen selber. Wenn ich einfach nur Daten von A nach B bekommen möchte, nehme ich ein Modul.
Wenn's um ein Hobby oder das Programmierenlernen geht, dann ist Ausprobieren der beste Weg, aber viele hier verdienen ihr Geld mit dem Programmieren, und da gibt's kein Extra-Lob dafür, dass man etwas selber geschrieben hat, statt ein Modul zu nehmen. Es kommt darauf an, dass es seinen Zweck erfüllt, und das möglichst fehlerfrei und bald (meist mit anderer Priorisierung). Da überlasse ich es gerne anderen, sich schon mit den "gory details" herumgeschlagen zu haben.
Die "einfache Lösung" kann manchmal eben blöde Fallstricke haben. Nehmen wir den Vorschlag von sid burn oben: "[...] Dann rechnest die Sekunden für 7 Tage wieder drauf, und rechnest die UTC Zeit wieder in ein normales Datum um (localtime)."
Okay, mach ich. Der Einfachheit halber habe ich mein erstes Datum schon als UNIX-Timestamp. Ein Tag hat 86'400 Sekunden, mal 7, ergibt die Sekunden, die ich addieren muss:
Ups, Moment mal! Sieben Tage nach dem 23. März kann doch nicht der 31. März sein? "Tja, tut uns leid, Frank Parker, du bist zu spät gestartet, der Präsident ist tot." Die Differenz in Sekunden stimmt zwar, aber trotzdem kommt nachher eine Stunde mehr heraus ...
Gut, das Beispiel ist gemein, aber es zeigt, was passieren kann, wenn man jemandem eine "einfache Lösung" zeigt, ohne auf die möglichen Probleme hinzuweisen.
Wie heißt es? "Zu Risiken und Nebenwirkungen fragen Sie den Autor oder das Perl-Community-Forum." ;)
Hoffe ich doch.
Wenn's um ein Hobby oder das Programmierenlernen geht, dann ist Ausprobieren der beste Weg, aber viele hier verdienen ihr Geld mit dem Programmieren, und da gibt's kein Extra-Lob dafür, dass man etwas selber geschrieben hat, statt ein Modul zu nehmen. Es kommt darauf an, dass es seinen Zweck erfüllt, und das möglichst fehlerfrei und bald (meist mit anderer Priorisierung). Da überlasse ich es gerne anderen, sich schon mit den "gory details" herumgeschlagen zu haben.
Die "einfache Lösung" kann manchmal eben blöde Fallstricke haben. Nehmen wir den Vorschlag von sid burn oben: "[...] Dann rechnest die Sekunden für 7 Tage wieder drauf, und rechnest die UTC Zeit wieder in ein normales Datum um (localtime)."
Okay, mach ich. Der Einfachheit halber habe ich mein erstes Datum schon als UNIX-Timestamp. Ein Tag hat 86'400 Sekunden, mal 7, ergibt die Sekunden, die ich addieren muss:
Code: (dl
)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#!/usr/bin/perl
use strict;
use warnings;
use Time::Local;
my $timestamp1 = 1143151500;
my $differenzTage = 7;
my $timestamp2 = $timestamp1 + $differenzTage * 86_400;
printf " Erstes Datum: %s (%d s)\n", scalar localtime($timestamp1), $timestamp1;
printf "%3d Tage später: %s (%d s)\n", $differenzTage, scalar localtime($timestamp2), $timestamp2;
__END__
Erstes Datum: Thu Mar 23 23:05:00 2006 (1143151500 s)
7 Tage später: Fri Mar 31 00:05:00 2006 (1143756300 s)
Ups, Moment mal! Sieben Tage nach dem 23. März kann doch nicht der 31. März sein? "Tja, tut uns leid, Frank Parker, du bist zu spät gestartet, der Präsident ist tot." Die Differenz in Sekunden stimmt zwar, aber trotzdem kommt nachher eine Stunde mehr heraus ...
Gut, das Beispiel ist gemein, aber es zeigt, was passieren kann, wenn man jemandem eine "einfache Lösung" zeigt, ohne auf die möglichen Probleme hinzuweisen.
Wie heißt es? "Zu Risiken und Nebenwirkungen fragen Sie den Autor oder das Perl-Community-Forum." ;)
Hoffe ich doch.