Datums-String umwandeln

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
reneschmidt
User
Beiträge: 48
Registriert: Montag 4. Januar 2016, 15:14

Hallo zusammen,

ich vermute ich habe ein relativ einfaches Problem:

Für eine Migration einer Vereinsverwaltung in eine Neue (die alte Arbeitet mit kuriosen CSV, DBF und zu allem Überfluss auch XLS Dateien und die neue Basiert auf einer MySQL Datenbank)

Da wir für eine gewisse Zeit einen Test fahren wollen in dem die Daten in der Original Datenbank bereinigt werden muss ein Script her um die Daten zu übernehmen.
Das funktioniert auch alles sehr gut nur leider komme mein alter Feind (Datetime) und ich wieder einmal nicht auf einen grünen Zweig:

Ich habe in den Import-Daten immer ein Datum in folgendem Format stehen: 19.02.69 und für die Migration brauche ich es in der amerikanischen Schreibweise (1969-02-19).
Wie kann ich das umwandeln?
Vereinfacht ausgedrückt wie mache ich aus "19.02.69" -> "1969-02-19" ?

Bisher habe ich

Code: Alles auswählen

mandatdatum = datetime.strptime(mitglieder[mg]["mandatsdatum"], '%d.%m.%Y'
probiert, mit dem Ergebnis:

Code: Alles auswählen

eintritt datetime.strptime(mitglieder[mg]["mandatsdatum"], '%d.%m.%Y')
                    ^
SyntaxError: invalid syntax
Vielen Dank für eure Hilfe.
Benutzeravatar
snafu
User
Beiträge: 6740
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

reneschmidt hat geschrieben:Vereinfacht ausgedrückt wie mache ich aus "19.02.69" -> "1969-02-19" ?

Code: Alles auswählen

from datetime import datetime
date = datetime.strptime('19.02.69', '%d.%m.%y')
print(date.strftime('%Y-%m-%d'))
Deine Fehlermeldung ist übrigens ein Syntaxfehler. Der hat nichts mit dem Datetime-Modul zu tun, sondern der entsteht, wenn man z.B. schließende Klammern vergessen hat.
Sirius3
User
Beiträge: 17750
Registriert: Sonntag 21. Oktober 2012, 17:20

@reneschmidt: Du willst ganz sicher keinen String als Datum haben, wenn die Daten in eine Datenbank wandern. Die Datenbank kann Datumfelder und die Schnittstelle kommt ganz gut mit Datetime-Objekten zurecht.
Benutzeravatar
noisefloor
User
Beiträge: 3856
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,
und für die Migration brauche ich es in der amerikanischen Schreibweise (1969-02-19).
Das ist übrigens nicht die amerikanischen Schreibweise, sondern ISO8601 (amerikanisch wäre auch mit / als Trenner) :-)

Aber, wie Sirius3 schon sagt: arbeite mit Datetime-Objekten, dann kannst du dir später bei Bedarf die Ausgabe ohne Probleme so formatieren, wie du möchtest.

Gruß, noisefloor
reneschmidt
User
Beiträge: 48
Registriert: Montag 4. Januar 2016, 15:14

Sirius3 hat geschrieben:@reneschmidt: Du willst ganz sicher keinen String als Datum haben, wenn die Daten in eine Datenbank wandern. Die Datenbank kann Datumfelder und die Schnittstelle kommt ganz gut mit Datetime-Objekten zurecht.
Leider ja.... Das neue System hat ein DB Feld in dem mehrer Informationen drin stehen die mit einem ; getrennt sind (Aufbereitung von Spendenbescheinigungen) und z.B. an der stelle brauche ich es so, da ich diesen Wert im Python Script zusammen baue. Das nur mal um ein Beispiel zu nennen.
Bei den normalen Felder kann ich es ja per Datetime Objekt rein schießen nur eben in diesen sonder Fällen nicht.

Vielen Dank für eure Hilfe.
Sirius3
User
Beiträge: 17750
Registriert: Sonntag 21. Oktober 2012, 17:20

@reneschmidt: in einer Datenbank sollten nie mehrere Informationen in einem Feld stehen. Notfalls kann man sich ja die zusammengesetzen Daten in einem View erzeugen, aber die Einzeldaten an sich müssen immer getrennt vorliegen. Da gibt es keine Sonderfälle.
Benutzeravatar
noisefloor
User
Beiträge: 3856
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,
Das neue System hat ein DB Feld in dem mehrer Informationen drin stehen die mit einem ; getrennt sind
Dann kannst du auch direkt bei einer CSV-Datei bleiben, da ist das auch so. Nur sparst du dir dann den Overhead eines RDBMS.

Basierend auf dem, was du sagst, klingt das Datenbankschema doch sehr "broken by design".

Gruß, noisefloor
Antworten