Zukünftige Datum berechnen

[FlyingFalcon]

Hallo miteinander!
Ich habe bisher ein bisschen mit Delphi gewerkelt und möchte nun das eine oder andere Programm mit Python erstellen. Habe jetzt Probleme mit den Datumsberechnungen. Die englische Sprache beherrsche ich leider auch nicht weshalb mir die Verweise aus diesem Forum auf die Docs nicht viel bringen. Die vielen Beispiele im Forum sind im Moment für mich noch verwirrend.
Meine Absicht:
Eine Arbeit/Tätigkeit mit Ruhetagen wird in einem bestimmten Rhythmus erbracht. Dieser Rhythmus wiederholt sich nach 140 Tagen. Starttag hierfür ist z. B. der 1.1.2001.
Ich möchte nun berechnen, welche Tätigkeit/Arbeit oder ein Ruhetag an einem bestimmten Tag in der Zukunft vorgesehen ist (nach dem Rhythmus).
Dieses Datum möchte ich immer frei bestimmen (Entry z. B.) und ab diesem Datum soll der Arbeitsplan für einen Monat ausgegeben werden.
Wie wird das Startdatum ausgelesen oder angegeben, dass ich damit rechnen kann? Welches Modul, time? datetime? Welche Funktionen davon?
In Delphi würde es so aussehen:
datum := EncodeDate(2001,01,01);
datum2 := DateTimePicker1.date);
tage := round(datum2 - datum);
Viele Funktionen und Delphi sind bequem. Wie kann das o. g. unter Python umgesetzt werden?
Kann jemand mich, dem Anfänger weiterhelfen?

Benutze Ubuntu 8.04 und möchte mich von XP ganz trennen.

Gruß FlyingFalcon

[BlackJack]

Ich hab's mal in Allgemeine Fragen verschoben, weil mit Daten rechnen nix mit GUI/Tkinter zu tun hat.

Mit Daten und Zeiten rechnen geht mit dem `datetime`-Modul:

Code: Alles auswählen

In [12]: start_date = datetime.date(2001, 1, 1)

In [13]: picked_date = datetime.date.today()

In [14]: days = (picked_date - start_date).days

In [15]: days
Out[15]: 2706

Um englische Dokumentation wirst Du nicht drum herum kommen.

[FlyingFalcon]

Danke für die schnelle Antwort.
Ich werde mich mal daran begeben und den Code für mich umzusetzen.
Mühseliges Vokabel übersetzen.
Ich hatte natürlich vor, das alles graphisch umzusetzen.

Danke BlackJack.

[audax]

http://en.wikipedia.org/wiki/Free_Pascal

OpenSource Pascal...vllt ist das ja was für dich :]

[numerix]

http://en.wikipedia.org/wiki/Free_Pascal

OpenSource Pascal...vllt ist das ja was für dich :]

Dann ist's aber Essig mit einer schönen GUI

Es gibt zwar einen Delphi-ähnlichen Aufsatz für GUIs Namens Lazarus, der RAD verspricht, aber nach meiner Erfahrung kann man damit nicht wirklich verlässlich arbeiten: http://www.lazarus.freepascal.org/ (Allerdings habe ich seit längerem nichts mehr damit gemacht - vielleicht ist die Stabilität ja inzwischen besser geworden.)

Schade, dass Kylix eingestampft wurde ...

[Leonidas]

Schade, dass Kylix eingestampft wurde ...

Nicht dass es etwas brauchbares war.

[numerix]

Schade, dass Kylix eingestampft wurde ...

Nicht dass es etwas brauchbares war.

Das hängt davon ab, was man damit vorhatte und was man bis dahin als Linux-User gewohnt war. Als jemand, der schon seit Jahren mit einem Windows-freien PC arbeitet, aber Software für Windows-Anwender erstellen muss bzw. will (mein Geld verdiene ich nicht damit) war Kylix für mich damals ohne jegliche Alternative. (Da ich kein Geld damit verdiene, will ich veständlicherweise auch kein Geld für eine Entwicklungsumgebung ausgeben).

Ich konnte komplett unter Linux entwickeln, musste danach irgendwann damit an einen Windows-Rechner mit Delphi-Installation (auch da gab es mal eine kostenlose "Personal-Version"), je nach Programm einige Anpassungen und/oder bedingte Compileranweisungen einbauen und fertig war das Windowsprogramm. Trotz der nicht 100%igen Kompatibilität von Delphi und Kylix ging das ganz gut, wenn man wusste, welche Features nicht ohne weiteres übertragbar waren.

Also, ich fand Kylix prima.

[lunar]

Schade, dass Kylix eingestampft wurde ...

Nicht dass es etwas brauchbares war.

Das hängt davon ab, was man damit vorhatte und was man bis dahin als Linux-User gewohnt war. Als jemand, der schon seit Jahren mit einem Windows-freien PC arbeitet, aber Software für Windows-Anwender erstellen muss bzw. will (mein Geld verdiene ich nicht damit) war Kylix für mich damals ohne jegliche Alternative.

Nicht, dass es keine anderen plattformunabhängigen Toolkits gegeben hätte...

Und ob Delphi jetzt ein wirklich gelungene Sprache ist, sei mal dahin gestellt ,)

[numerix]

Nicht, dass es keine anderen plattformunabhängigen Toolkits gegeben hätte...

Zum Beispiel?

Und ob Delphi jetzt ein wirklich gelungene Sprache ist, sei mal dahin gestellt ,)

Wenn man mit Pascal aufgewachsen ist und die Programmierung nur in der knapp bemessenen Freizeit betreibt, dann ist man froh, dass es wenigstens Delphi gibt.

[lunar]

Nicht, dass es keine anderen plattformunabhängigen Toolkits gegeben hätte...

Zum Beispiel?

wxWidgets?

[numerix]

Nicht, dass es keine anderen plattformunabhängigen Toolkits gegeben hätte...

Zum Beispiel?

wxWidgets?

Wie soll ich das Fragezeichen verstehen? ICH weiß es nicht.

WAS ich weiß, ist, dass ich 2001 mit Kylix unter meiner damaligen Arbeitsumgebung (SuSE 7.2) das konnte, was ich oben beschrieben habe.
Und selbst, wenn wxWidgets damals schon so weit war: Dann hätte ich mich erst in C++ einarbeiten müssen ...

[lunar]

Nicht, dass es keine anderen plattformunabhängigen Toolkits gegeben hätte...

Zum Beispiel?

wxWidgets?

Wie soll ich das Fragezeichen verstehen? ICH weiß es nicht.

Im Sinne von "Wie wäre es beispielsweise mit wxWidgets?".

WAS ich weiß, ist, dass ich 2001 mit Kylix unter meiner damaligen Arbeitsumgebung (SuSE 7.2) das konnte, was ich oben beschrieben habe.
Und selbst, wenn wxWidgets damals schon so weit war: Dann hätte ich mich erst in C++ einarbeiten müssen ...

wxPython gab es 2001 auch schon mindestens drei Jahre

[numerix]

WAS ich weiß, ist, dass ich 2001 mit Kylix unter meiner damaligen Arbeitsumgebung (SuSE 7.2) das konnte, was ich oben beschrieben habe.
Und selbst, wenn wxWidgets damals schon so weit war: Dann hätte ich mich erst in C++ einarbeiten müssen ...

wxPython gab es 2001 auch schon mindestens drei Jahre

Ja, DASS es das damals schon gab, war auch für mich nicht schwer zu recherchieren. Aber die Informationen, die ich gefunden habe, reichen (jedenfalls für mich) nicht aus, um beurteilen zu können, AUF WELCHEM STAND wxWidgets damals war, ob es z.B. als fertiges Paket lauffähig für meine damalige Arbeitsumgebung verfügbar war und wie brauchbar die Entwicklungsumgebung war.

Nach deinem Posting

Nicht, dass es keine anderen plattformunabhängigen Toolkits gegeben hätte...

(immerhin Plural!) hatte ich mit mehr gerechnet als dem Hinweis auf EIN Toolkit, von dem du anscheinend ja auch nicht weißt, inwiefern es tatsächlich zum damaligen Zeitpunkt eine echte Alternative gewesen wäre. Die Existenz eines entsprechenden Toolkits sagt über seine Brauchbarkeit ja noch nichts aus.

[Leonidas]

Es gibt ja auch die Möglichkeit mehrere UI-Toolkits je nach Platform zu verwenden, wie das bei einigen Programmen üblich ist.

Und Kylix zum entwickeln von Delphi-Programmen zu verwenden ist wohl auch der einzige Nutzen. Da würde ich dann aber sowieso eher Delphi verwenden. Kylix hat zu Linux einfach nicht gepasst und ich schätze mich glücklich, nicht über Kylix-Sachen in Linux zu stolpern.

[lunar]

WAS ich weiß, ist, dass ich 2001 mit Kylix unter meiner damaligen Arbeitsumgebung (SuSE 7.2) das konnte, was ich oben beschrieben habe.
Und selbst, wenn wxWidgets damals schon so weit war: Dann hätte ich mich erst in C++ einarbeiten müssen ...

wxPython gab es 2001 auch schon mindestens drei Jahre

Ja, DASS es das damals schon gab, war auch für mich nicht schwer zu recherchieren. Aber die Informationen, die ich gefunden habe, reichen (jedenfalls für mich) nicht aus, um beurteilen zu können, AUF WELCHEM STAND wxWidgets damals war

Nach neun Jahren sollte ein Software eine gewisse Reife haben Kylix zumindest war damals imho auf keinem guten Stand...

Nach deinem Posting

Nicht, dass es keine anderen plattformunabhängigen Toolkits gegeben hätte...

(immerhin Plural!) hatte ich mit mehr gerechnet als dem Hinweis auf EIN Toolkit, von dem du anscheinend ja auch nicht weißt, inwiefern es tatsächlich zum damaligen Zeitpunkt eine echte Alternative gewesen wäre.

Ich kenne deinen Hintergrund nicht, also habe ich das Toolkit erwähnt, welches zum damaligen Zeitpunkt wohl das universalste war. Ich persönlich beispielsweise hätte 2001 beispielsweise Java mit Swing genutzt.

[numerix]

Und Kylix zum entwickeln von Delphi-Programmen zu verwenden ist wohl auch der einzige Nutzen. Da würde ich dann aber sowieso eher Delphi verwenden.

Dann hätte ich aber unter Windows entwickeln müssen, und das wollte ich einfach nicht.

Nach neun Jahren sollte ein Software eine gewisse Reife haben

Klar, SOLLTE. Vielleicht äußert sich ja noch jemand, der es aus eigener Erfahrung (von damals) WEIß.

Kylix zumindest war damals imho auf keinem guten Stand...

Ja, da muss ich dir Recht geben. Kylix 1 war wohl mehr noch ein Experiment.
Mit Kylix 3 (Release-Datum weiß ich nicht mehr) wurde es aber dann deutlich besser.

Ich persönlich beispielsweise hätte 2001 beispielsweise Java mit Swing genutzt.

Das habe ich dann 2 Jahre später auch getan.
Echte Programmierfreude kommt bei mir da aber bis heute nicht auf.

Wie gut, dass es Python gibt.

[lunar]

Swing ist imho definitiv besser als das GUI Toolkit von Kylix, da wesentlich moderner und besser designed.

[numerix]

Swing ist imho definitiv besser als das GUI Toolkit von Kylix, da wesentlich moderner und besser designed.

Das kann durchaus sein. Das Maß an "Programmierfreude" hat sicher immer auch mit den verwendeten Tools und der entsprechenden Entwicklungsumgebung zu tun. Die ist bei Delphi/Kylix eben vorgegeben und aus einem Guss.

Delphi/Kylix war für mich damals der erste - zunächst überaus angenehme - Kontakt mit einer RAD-Umgebung. Dass solchermaßen zusammengebastelte GUIs letztlich wenig robust gegenüber z.B. Änderungen der Schriftgrößen oder den installierten Fonts, Varianten des Betriebssystems usw. sind merkt man natürlich irgendwann.

Bei Java/Swing habe ich mich nie mit Eclipse, NetBeans o.ä. anfreunden können, wahrscheinlich, weil meine Projekte dafür einfach zu klein sind und ich zu selten wirklich zum Programmieren komme. Da bin ich irgendwann bei BlueJ hängen geblieben - für meine Bedürfnisse genau richtig. Aber das heißt dann eben auch: Das ganze Layoutmanagement etc. per Hand zusammenbasteln und das macht mit Swing wirklich keinen Spaß.