Lightning CSV-Import geht nicht? – So geistert es seit Jahren zumindest durch deutsche Foren.
Geht natürlich doch, ist wie immer, das Problem sitzt vor der Tastatur, diesmal aber nicht der gemeine DAU sondern der DAP.
Ist ja schön wenn man eine CSV-Export-Funktion programmiert und dann vergisst auch mal auszuprobieren ob das alles so ganz richtig rauskommt. Dem normalen Anwender hilft es nicht.
Es gilt der gute alte Spruch, den wir in meinen Anfangszeiten meiner Computerei generiert haben. Das was die Zeit in der man die CPU noch in ihrer natürlichen Sprache anredete und Hersteller von Debuggern und Disassemblern am Hungertuch nagten, weil man sich die 80 OP-Codes merken konnte und die Dinger schlicht im HEX-Editor lesen und bearbeiten konnte.
"Der Computer ist an allem Schuld, dabei kann er nichts dafür! Er kennt nur NULL und EINS, seine Intelligenz bekommt er durch ein Programm und jedes Programm ist nur so intelligent wie der Programmierer, der es geschrieben hat. – Darum gibt es so viele sauschlechte Anwendungen!"
Ist schon ein paar Jahrzehnte alt und wird in ein paar Jahrzehnten/Jahrhunderten immer noch gültig sein.
Vorab bemerkt alle die Zugang zu Outlook haben können jetzt aufhören zu lesen, die Importieren ihre CSV-Dateien in Outlook, exportieren von dort als iCalender-Datei (.ics) importieren dann diese in Lightning. Outlook importiert aus CSV-Dateien wesentlich mehr wie Thunderbird/Lightning und wenn dann soll der Termin schon enthalten, dass er bestätigt ist, nicht dass das Vorzimmer meiner geneigten Vorstandsmitglieder glaubt, da könnte man dran rumbasteln, Vorstandssitzung ist Vorstandsitzung.
Und jetzt noch ganz schnell, bevor die Outlook-Besitzer weg sind: Die nötige Tabelle erstellt man in LibreOffice Calc und nicht im mit Outlook mitgelieferten MS Excel! Warum das? Weil Mikrodoof glaubt, dass es seine Kunden schon zu kompletten Vollidioten, die nicht wissen was sie tun, umerzogen hat. Die Blindgeister aus Redmond nutzen beim Export in eine CSV-Datei nämlich automatisch den landesspezifischen Delimiter, damit der Anwender nicht durcheinander kommt, in Deutschland ';', ganz blöde Idee! Viele Anwendungen mögen es nur America Only! Da heißt das Ding nun mal ',' und was anderes verstehen sie nicht!
Wer also nicht jedesmal die Einstellung seines Computers von 'Deutsch' nach 'US' und wieder zurück ändern möchte nutzt LibreOffice Calc. Da kann man nämlich beim Export in eine CSV-Datei vorgeben welchen Delimiter man gerne hätte, im Zweifel das US-verträgliche ','. Das kommt auch auch zum Tragen wenn man mehrere Kategorien hinzufügen möchte, muss ',' und nicht ';' als Delimiter sein.
Nachdem ich zu denen mit Zugang zu Outlook gehöre und dort der CSV-Import deutlich mehr kann war mir das bisher ehrlich gesagt auch gleich. Jetzt haben wir aber einen jungen Aktiven ohne selbiges hinzubekommen und der soll eben künftig in Veranstaltungseinladungen mittels des QR-Code-Generators von Harald Judt selbigen in diese einbauen und beim Mailversand die iCalendar-Datei mit dem Termin, die er zuvor mittels ICS Inspector gespeichert hat mitschicken. Wenn man da nicht für ein Meeting mit begrenzter Teilnehmerzahl einlädt empfehle ich da einen Kalender OHNE eMail-Adresse zu benutzen, schon gar nicht mit der eigenen Standardadresse, macht irgendwie keinen Spass wenn man dann plötzlich ein paar hundert Zu- oder Absagen zu einer Vortragsveranstaltung drin hat. Also Augen auf bei der Kalenderanlage "Keine" muss da bei eMail-Adresse stehen.
Als geeignete Vorgehensweis wird meist empfohlen einen Kalender als CSV-Datei zu exportieren und kann dann nachlesen, dass der umgekehrte Weg nicht funktioniert hat.
Tut er aber, man muss nur mal analysieren was man da exportiert hat und den Fehler beseitigen.
Folgende Vorgehensweise führt zum Ziel.
Erst legt man sich einen neuen Testkalender an, dort erzeugt man in Lightning einen Termin um 7 Uhr, Dauer 4 Stunden, 2 Stunden Vorwarnzeit, zwei/drei Kategorien (damit man sieht wie der Delimiter aussehen muss) ein wenig Text in der Notiz. Den duplizieren wir und ändern beim Duplikat, den Beginn auf 19 Uhr, alles andere ändert sich dann einsprechend.
Diesen Kalender exportieren wir, dann finden wir nachstehende Kopfzeile vor.
"Subject","Start Date","Start Time","End Date","End Time","All day event","Reminder on/off","Reminder Date","Reminder Time","Categories","Description","Location","Private"
Von dem was drunter steht greifen wir mal zwei Einträge heraus, die einem Deutschen/Österreicher/Schweizer, etc. schmerzen bereiten (können).
"Start Date", da steht sowas wie "02/07/17" drin, wir stellen also fest, die Amis sind genauso blöd wie die Deutschen und können kein normgerechtes numerisches Datum nach ISO 8601.
Da steht also übersetzt "MM/DD/YY" und genau dieses oder "MM/DD/YYYY" dann ist das Jahr wenigstens korrekt vierstellig, wie seit 2004 Vorschrift, funktioniert beim Import. Weder das korrekte numerische Datum nach ISO 8601:2009 YYYY-MM-DD noch das veralte TT.MM.JJJJ funktionieren – America Only.
Beim Datum heißt es also "Monat/Tag/Jahr", alles zweistellig, das Jahr kann und muss eigentlich vierstellig sein.
Unter der Kopfzeile folgen zwei Zeilen mit dem jeweiligen Termineintrag, da greifen wir jetzt noch die Uhrzeit heraus, exemplarisch "Start Time".
Unter der Kopfzeile steht in Zeile 2 "07:00:00 " und in Zeile 3 steht "07:00:00 "
Das Leerzeichen nach der Uhrzeit steht da tatsächlich, ist kein Fehler und ist auch der Hinweis warum ich mich frage warum da bisher soviele keinen Import hinbekommen haben.
Wir hatten 7 Uhr und 19 Uhr eingetragen und jetzt steht da zweimal "07:00:00 ", das kann doch gar nicht sein. Kann es wohl, den Amis fehlt, soweit ungedient, die Umschulung auf die 24-Stunden-Uhrzeit, die die Deutschen bereits erfolgreich durchlaufen haben. – Bin ja gespannt wie lange das beim numerischen Datum noch dauert, der 1. Mai 1996 ist ja schon eine Weilchen her und somit gilt eigentlich seit zwei Jahrzehnten JJJJ-MM-TT, ok bis 2004 durfte man die Jahreszahl auch zweistellig schreiben, seither ist dann doch allen aufgefallen, dass man nur dann korrekt danach sortieren kann wenn es vierstellig ist, dazu hat's die Jahrtausendwende gebraucht, zur Entstehungszeit der DIN EN 28601 war das noch kein Thema.
Hier finden wir auch den Fehler warum bisher soviele ein Problem beim Import hatten. Auch in Amiland muss eine Uhrzeit, die importiert werden soll, eindeutig sein, trotz 12-Stunden statt 24-Stunden. Der Schlamper, der die CSV-Exportfunktion geschrieben hat ist ein grober Pfuscher (DAP), der sich das Exportergebnis offensichtlich noch nie selbst angesehen hat. Damit es eindeutig ist muss da jeweils NACH dem Leerzeichen, das schon da ist, noch "AM"/"am" oder "PM"/"pm" dazu. Kann man schreiben wie man will ist "case insensitive", aber da sein muss es.
"07:00:00 AM" und "07:00:00 PM" hätten da exportiert werden müssen und genau das muss man beim Import auch liefern, "hh:mm:ss am" oder "hh:mm:ss pm", dann klappt's auch mit dem Import.
Und noch ein kleiner Hinweis, wenn Excel oder Calc per Autokorrektur irgendwo aus " - " ein " – " also Halbgeviertstrich statt Divis gemacht haben sollte, dann ist das zwar korrekt, beim Gedankenstrich oder Ersatz für "bis" soll das so sein, nicht aber bei Lightning im Subject oder sonst wo, da steht dann meist kein Strich, soviel zu Ami und nicht ASCII-Zeichensatz. Achtet da also drauf und ersetzt nötigenfalls zurück.
