Lightning CSV-Import geht nicht? – Geht doch, hier die Lösung!

  • 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.

  • Hallo,


    da warst du ja sehr fleißig. Leider hast du das Wichtige in Unmengen von Arroganz, selbstherrlichem Gesabbel und schlichtem Unsinn vergraben, was deinen Beitrag leider sehr entwertet. Lass die kindische Ideologie weg (Mikrodoof? auweia!), dann sparst du 90% vom Text und es bleiben straffe, übersichtliche und dann eventuell hilfreiche Beiträge übrig.


    MfG
    Drachen

  • Vielleicht weil die Überschrift "Lightning CSV-Import geht nicht? – Geht doch, hier die Lösung!" lautet – nicht "... CSV-Export geht nicht ..." (der geht ja zumindest fehlerhaft – und ist die Ursache warum man jahrelang Hilferufe dazu im Netz finden konnte, wurde allenthalben als Muster genommen und das war der GAU).


    Im Übrigen bin ich in "unserer" Welt auch sofort bei Dir und iCalendar, außerhalb unseres geschützten Biotops gibt es aber leider auch noch so eine böse, reale Welt.


    Das ist die, in der irgendwelche Tipp-Äffchen mühsam erlernt haben eine Maske am Bildschirm auszufüllen und auf deren Stirn "RAPIST" eingebrannt wurde, weil sie Word/Writer täglich als Schreibmaschine vergewaltigen. Wo du den hauptamtlichen Mitarbeitern eines Vereins/Verbandes eine Veranstaltungseinladung als PDF-Datei zusammen mit einer iCalendar-Datei mailst, den Auftrag zum versenden beider Dateien an den kompletten Mitgliederverteiler erteilst und wenn Du dann nachfragst warum nur die PDF-Datei verschickt wurde, als Antwort "Da hab I ned g'wusst was des soll, drum hab' I 's weglassen." (Was das Ding soll stand in der Mail mit dem Versandauftrag) bekommst.


    Die Welt in der du die Fraktionssprecherin der anderen Fraktion fragst, was denn die Nachrückerin, die sie dir in den Unterausschuss geschickt hat, für eine eMail-Adresse hat, damit du Ihr die Tagesordnung, sowie Unterlagen zu mailen kannst und die Antwort lautet: "Da arbeiten wir dran, bis jetzt hat sie noch keinen Rechner." In der eigenen Fraktion eine sitzt, die in der letzten Amtsperiode das selbe Problem hatte und nachdem man man sie zu einem genötigt hat, vier Wochen nachdem man die Termine als Tabelle, Kalenderblatt und ICalendar-Datei(en) an alle verschickt hat nachfragt wann sie denn endlich einen Ausdruck mit den Terminen des nächsten Jahres bekommt.


    Und so bekommst Du die Termine auch, wenn Du Glück hast als Tabellen, wenn Du Pech hast irgendwie unstrukturiert. Nachdem man für die Ausdruckfreaks ja ohnehin ein Tabelle mit den Terminen braucht, hat man schon eine Tabelle mit z. B. 7 x 12 Terminen. Termine die sich nicht immer am selben Tag im Monat wiederholen, weil sie sich durch Ferien und Feiertage verschieben. Bei meist gleichbleibendem Tagungsort und Anfangszeit braucht man da nur den Namen des Unterausschusses ändern und das jeweilige Sitzungsdatum einkopieren. Copy und Paste in Excel oder Calc und nachdem sich in einer Amtperiode nichts ändert muss man die Tabelle(n) für die Vollversammlung, Unterausschüsse, Vorstand nur einmal erstellen, in den fünf Folgejahren reicht es einfach die Spalte mit dem jeweiligen Sitzungsdatum aus der Tabelle mit allen Terminen zu kopieren und dreimal einzufügen. Als CSV-Datei exportieren und in Outlook oder Lightning importieren.


    Das ist kein Umstand, das ist mit Sicherheit deutlich bequemer, effizienter und schneller wie die Termine in Outlook oder Lightning zu erstellen, duplizieren und an den passenden Platz zu befördern. Das geht in Excel oder Calc deutlich besser.


    Nachdem weder Outlook noch Calc eine ICalendar-Export-Funktion eingebaut haben ist das Format für den Import großer Termin-Mengen, die schon irgendwo und irgendwie als Tabelle vorliegen eben nicht .ics sondern .csv, zumal das Zeugs ja ohnehin in Lightning hinein muss, damit man einen QR-Code generieren kann, also kann man es auch gleich von dort wieder als .ics-Datei abspeichern und muss das nicht als Makro ins Spreadsheet mit rein packen.


    Beim Export zum Verteilen bin ich dann wieder bei Dir und iCalendar (.ics).


    Gruß
    NutztThunderbird

  • Schade, dass offenbar neuere Thunderbird-Versionen neuere Schwierigkeiten beim Umgang mit dem csv-Import produzieren.

    Der Hinweis von NutztThunderbird hat mich immerhin auf die Spur gebracht, um das Problem mit einer älteren Version (so ca. 45.x.x ?) vorübergehend zu lösen. Allerdings mussten die Einträge durchaus case-sensitive gemacht werden: für die Uhrzeit hh:mm:ss AM und auf keinen Fall hh:mm:ss am. Entsprechend das Jahr auf jeden Fall vierstellig , also MM/DD/YYYY und nicht MM/DD/YY.

    Außerdem musste die Angabe bei All-Day-Event auf jeden Fall "True" und nicht "true" sein.

    Ach ja: und alle Einträge in Hochkommas.

    Dann hat es einigermaßen reibungslos funktioniert. "Einigermaßen", weil es beim Import immer zu einem Absturz gekommen ist, die Termine aber offenbar trotzdem alle da waren. Eine Fehlermeldung erfolgte nicht.

    Tja, und dann habe ich Thunderbird auf 52.2.1 akutalisiert.

    Jetzt ist es wieder vorbei mit dem Import - immerhin nun mit Fehlermeldung:



    Konnte nicht von Datei lesen:D:\Benutzer\xxxxx\Desktop\testkalender.csv


    [Exception... "[JavaScript Error: "locale is not defined" {file: "resource://calendar/modules/calUtils.jsm -> file:///C:/Users/xxxxx/AppData/Roaming/Thunderbird/Profiles/aw03o5my.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calOutlookCSVImportExport.js" line: 245}]'[JavaScript Error: "locale is not defined" {file: "resource://calendar/modules/calUtils.jsm -> file:///C:/Users/xxxxx/AppData/Roaming/Thunderbird/Profiles/aw03o5my.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calOutlookCSVImportExport.js" line: 245}]' when calling method: [calIImporter::importFromStream]" nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)" location: "JS frame :: chrome://calendar/content/import-export.js :: loadEventsFromFile :: line 85" data: yes]


    Hat jemand eine Idee, woran es liegen könnte?


    Vielen Dank schon mal im Voraus!

    Gruß

    zerbi