Terminkalender mit Import aus Datei und längerer Erinnerungsdauer

[secondhandbanana]

Aktuell verwende ich in Jorte den CSV-Import um meine Termine zu aktualisieren und den Calendar Event Reminder um wiederholende Erinnerungen bis zu einer Bestätigung zu erhalten. Ich möchte dazu immer den gesamten Kalender durch die importierten Daten ersetzen (was so auch funktioniert) und muss natürlich auf eine Synchronisation in die umgekehrte Richtung verzichten. Der Import ist leider nur über eine Datei möglich und die Verwendung von Onlinediensten scheidet in diesem Fall auch aus.

Der Haken an der o.g. Lösung ist, dass der Calendar Event Reminder nur für Termine in einem Google Kalender funktioniert. Den kann ich mit Jorte zwar auch lokal anlegen und die Erinnerungen funktionieren zumindest auf den ersten Blick wie gewünscht, aber der CSV-Import in Jorte geht immer nur in den Jorte-Kalender so dass die Erinnerungen mit dem Calendar Event Reminder nicht funktionieren.

Gibt es einen anderen Kalender mit dem das gewünschte funktioniert oder eine Lösung wie das mit Jorte zu realisieren ist?

 

[Rak]

Hi, offensichtlich verwendest du die eigene Datenbank von Jorte. Damit kommt wohl keine andere App zurecht, meine ich.

Import in lokale Kalender geht mit guten Kalender-Apps wie "CalenGoo" und "Business Calendar Pro", die auch bereits selbst wiederholende Erinnerungen und auch Schlummerfunktionen bieten.

 

[secondhandbanana]

Danke für die Antwort. Ich verwende bei Jorte zwar einen lokalen Google Kalender, aber der Import geht anscheinend nur in die Jorte eigene Datenbank.

Ich habe den Business Calendar mal ausprobiert und der wäre vom ersten Eindruck her auch voll OK. Leider kann ich den ICS-Import in der kostenslosen Version nicht testen. Ist es möglich, den kompletten Kalenderinhalt durch die importierten Daten ersetzen zu lassen (geht bei Jorte) oder werden die importierten Daten immer hinzugefügt? D.h. muss ich den Kalenderinhalt vorher manuell löschen und wenn ja, wie geht das (ich habe im Business Calendar keinen Menüpunkt dazu gefunden, habe aber auch noch nicht die Pro-Version)?

 

[Rak]

Das weiß ich leider nicht, ich importiere nicht. Für mich ist Synchronisieren besser und einfacher.

Ich gehe aber davon aus, nicht der komplette Kalender ersetzt wird, sondern lediglich die einzelnen Termine importiert werden. In der Regel geht es ja auch um einzelne verschickte Termine. Dass jemand wie du alle anderen Termine löschen will, ist eher ungewöhnlich.

 

[__W__]

...werden die importierten Daten immer hinzugefügt?

Ja, Import wird hinzugefügt. Ein zentraler "Löschpunkt" ist auch nicht vorhanden. Allerdings kann man in der Terminübersicht die Mehrfachauswahl aktivieren und dann via Zeitraumangabe "global" selektieren.

Allerdings sollte man, wenn man dauernt löscht und dann neue Termine anlegt die reale Datenbankgröße (calendar.db unter /data/data/com.android.providers.calendar) im Auge behalten, da die Daten in der Datenbank (erstmal) nicht gelöscht, sondern nur als gelöscht markiert werden.
Die Datenbank wird auf diese Weise schnell sehr groß.

Abhilfe schaft dann ein "Datenbankoptimiertungdurchlauf", wie ihn z.B. die App "Android Tuner" zur Verfügung stellt.

Daher ist "Syncronisieren" eigentlich die bessere Wahl.

Gruß __W__

 

[secondhandbanana]

Ich würde natürlich auch lieber synchronisieren, aber als Ausgangsbasis habe ich leider nur eine exportierte Datei eines anderen Kalenders und möchte keine direkte Verbindung zu dem System auf dem der Kalender läuft herstellen. Außerdem wird der Kalender nicht 1:1 übernommen, sondern die Einträge werden zuvor noch gekürzt da es mir eim Wesenlichen nur darum geht, die Erinnerungen und den Betreff zu sehen. Ich könnte mir natürlich auch eine Lösung vorstellen, die den Kalender mit der Datei abgleicht und dabei nur in eine Richtung "synchronisiert" (d.h. nur Änderungen vornimmt), aber das wird wohl noch schwerer zu finden sein. Gibt es das problem mit der ständig wachsenden Datenbank trotz wieder gelöschter Einträge eigentlich immer, nur wächst diese dann langsamer als wenn man jedes Mal alles löscht und wieder neu anlegt?

 

[__W__]

Gibt es das problem mit der ständig wachsenden Datenbank trotz wieder gelöschter Einträge eigentlich immer, nur wächst diese dann langsamer als wenn man jedes Mal alles löscht und wieder neu anlegt?

Das beschriebene selektierte alles löschen ist genauso wie einzeln löschen => Datenbank wächst rasant.

Es gibt AFAIK nur zwei Möglichkeiten die Datenbank auf Format zu halten:

1. oben genannte Datenbankbereinigung ( SQL => VACUUM), dabei wird die Datenbank (intern) neu aufgebaut und indiziert. Alle "nicht gelöschten" Daten bleiben erhalten. Wird sehr wahrscheinlich ROOT benötigen.

2. oben genannte Datenbankdatei und dazugehörige -journal-Datei löschen (das "Grundgerüst" wird nach einem Neustart normalerweise neu angelegt). Benötigt ROOT.
<=>
im Appmanager bei der App Kalenderspeicher die Daten löschen.
Entscheidender Nachteil, es müßen alle Kalender neu angelegt werden.

Gruß __W__

Edit: Das Datenbankproblem betrifft meine Erfahrung nach alle Datenbanken unter Android (zumindest bis 4.1x) und einige "Systemtuning"-App machen meist nichts anderes als alle Datenbanken zu bereinigen. Es gibt dann ein riesen Bohei um die tolle Wirkung der App, weil dann alles ein bischen schneller läuft, aber keiner sagt einem warum das so ist und was denn wirklich "getuned" wurde => ganz großes Geheimnis

 

[secondhandbanana]

Ich glaube fast, ich habe eine - unter den gegebenen suboptimalen Rrandbedingungen - brauchbare Lösung gefunden um die genannten Schritte möglichst bequem auszuführen. Mit "iCal Import/Export 2.1" kann ich direkt in den gewünschten Kalender importieren und sogar ganz einfach auswählen, dass dieser zuvor gelöscht werden soll. Jetzt muss bin ich dran und muss die Daten nur noch im passenden Format anliefern...

Das Gerät ist nicht gerootet (und ich habe das aktuell noch nicht vor), aber "vacuum" der Datenbank müsste doch durch Export aller lokalen Google-Kalender, löschen der Daten des Kalenderspeichers und Import nach Neuanlegen der Kalleender zu bewerkstelligen sein, oder? Da die Termine im Wesentlichen nur aus Betreff+Uhrzeit bestehen müsste das ja nicht so besnders oft erforderlich sein.

 

[__W__]

... durch Export aller lokalen Google-Kalender, löschen der Daten des Kalenderspeichers ...

Juup, das sollte funktionieren, voraus gesetzt du syncronisierst mit Google (erspart auch den Export) und löscht die Kalendereinträge dort via Webfrontend. Dort kannst du auch den Import in verschiedensten Formaten vornehmen. Sonst mußt du alle Kalender erst neu anlegen.

Der/die Google-Kalender sind keine sogenannten "lokale" Kalender, auch wenn man die Syncronisation abgestellt hat. Lokale Kalender besitzen keinen eigenen Syncadapter und syncronisieren daher nur mit zusätzlicher Software, auch wenn die eigentlichen Daten in der selben Datenbank liegen .

Gruß __W__

 

[secondhandbanana]

Bei den exakten Begriffen bin ich wohl manchmal noch etwas unsicher. Ich meine natürlich den "lokalen" Kalender den man auf dem S2 Plus einrichten kann, bei Jorte ist der unter der Kategroie "Google" aufgeführt.

Jetzt funktioniert's mit "iCal Import/Export 2.1" fast perfekt (sogar ein Update von Terminen wird erkannt), abgesehen von einem winzigen Problemchen. Die Termine werden fast alle korrekt übernommen, d.h. alle bis auf endlich viele.

Einzeltermine sind kein Problem, aber bei Terminserien scheinen die Zeiten nur für das halbe Jahr zu stimmen, in dem Sommer-/Winterzeit mit dem Starttermin identisch ist. D.h. Terminserien die z.B. bei Winterzeit begonnen haben werden aktuell korrekt dargestellt, ab April stimmen aber die Zeiten nicht mehr. Bei Serien die bei Sommerzeit angefangen haben ist es genau umgekehrt. Einzeltermine passen immer.

In der exportierten ICS-Datei ist als Zeitzone "W. Europe Standard Time" definiert, und zwar so, dass es MEZ inkl. Sommerzeit entspricht. Diese Zeitzone wird bei allen Terminen explizit angegeben. Technisch ist das OK, aber die Namensgebung ist unglücklich wegen der Verwechslungsgefahr mit der "Western European Time" (Portugal, ...).

Es sieht für mich so aus, als ob der Starttermin in eine Zeitzone ohne Sommerzeit (z.B. UTC) umgerechnet und damit die Serie eingetragen wird.

Ist das ein Problem des (lokalen) Kalenders oder des Imports? D.h. enthält das interne Kalenderformat überhaupt die Möglichkeit eine frei definierte Zeitzone mit anzugeben?

 

[__W__]

... enthält das interne Kalenderformat überhaupt die Möglichkeit eine frei definierte Zeitzone mit anzugeben?

... keine Ahnung, ist mir bisher noch nicht unter gekommen .

Start- und Endzeit werden bei mir als Z-Zeit (Zulu-Zeit) abgelegt, das entpricht UTC => aus dem "21.02.2014 14:00 Europe/Berlin" wird "20140221T130000Z".

Mach ja auch Sinn, da es die Anzeige für alle "kalulierbar" macht, besonders wenn man die Zeitzone wechselt.

Gruß __W__

Edit: ... kleine Korrektur, Start- und Endzeit werden auch als Unixzeit mit eingerechneter Zeitzone abgelegt, allerding mit 3 Stellen (Nullen) mehr als ich gewohnt bin, daher übersehen => aus dem "21.02.2014 14:00 Europe/Berlin" wird 1392987600000

 

[secondhandbanana]

Start- und Endzeit dürfen eigentlich nicht als Z angegeben werden, da ein Termin z.B. um 15:00 UTC im Winter um 16:00 und im Sommer um 17:00 wäre. D.h. der Termin benötigt schon die Zeitzoneninfo, insbesondere wegen der Sommer-/Winterzeitregel (die Umstellungstermine können z.B. in anderen Gegenden abweichen).

Ich glaube, ich habe die Ursache des Problems gefunden, wenn auch ich noch nicht alles so ganz verstanden habe. Die importierten Termine werden in Jorte mit der Zeitzone "Berlin" angezeigt, wenn ich aber das Zeitzonenauswahlfeld des Termins öffne erscheint "Niue" selektiert. Das ist zufällig der erste Eintrag der Liste. Wenn ich das dann speichere, wird es auch in Zukunft angezeigt und ggf. auch mit exportiert. Wenn ich die Termine dagegen ohne Änderung exportiere haben sie gar keine Zeitzone. Wenn ich die Zeitzone einer Terminserie händisch auf "Berlin:GMT+1:00" (wieso eigentlich noch GMT und nicht UTC?) stelle stimmt die Zeit sowohl im Sommer, als auch im Winter und bei einem Export steht auch "Berlin..." als Zeitzone in den Start- und Endzeiten der Termine.

D.h. beim Import ist die Zeitzone irgendwie nicht so richtig mitgekommen, obwohl "Berlin" (ohne GMT...) angezeigt wurde. Anscheinend hat das etwas mit dem Namen "W. Europe Standard Time" oder der recht komplizierten Definition dieser Zeitzone zu tun.

Wenn ich jetzt die Definition der Berlin-Zeitzone aus der testweise exportierten ICS-Datei in die zu importierende Datei kopiere und "W. Europe Standard Time" durch "Berlin..." ersetze, funktioniert auch der Import vollständig fehlerfrei sowohl im Sommer als auch im Winter. D.h. ich habe die Zeitzonendefinition in der ICS-Datei durch die (eigentlich identische) von Android ersetzt und damit funktionierts.

Das ist zwar nicht besonders schön, lässts sich aber gut automatisieren.

 

[__W__]

Start- und Endzeit dürfen eigentlich nicht als Z angegeben werden, da ein Termin z.B. um 15:00 UTC im Winter um 16:00 und im Sommer um 17:00 wäre. D.h. der Termin benötigt schon die Zeitzoneninfo, insbesondere wegen der Sommer-/Winterzeitregel

... gerade deswegen macht es Sinn eine Zeit mit "fester/allgemeingültiger" Zeitbasis zu speichern.
Man spart sich einen Hintergrundberechnungsvorgang, wenn man z. B. im Urlaub in den USA ist können einem die "Heimtermine" mit nur einem Berechnungsschritt in Ortszeit angezeigt werden und die Erinnerung für den Anruf zum Geburtstag der Schwiegermutter muß nicht erst von der Heimzeitzone "runter" auf Basiszeit und dann "rauf" auf Standortzeit gerechnet werden.



Gruß __W__

 

[secondhandbanana]

Ich hatte es versehentlich nicht explizit erwähnt, dass ich bzgl. der Zeitzone von Serienterminen ausgegangen bin. Bei Einzelterminen funktioniert eine einmalige Umrechnung nach UTC natürlich problemlos. Ein Termin, der aber z.B. an jedem letzten Mittwoch im Monat um 9:00 stattfindet würde im Sommer- und im Winterhalbjahr zu verschiedenen UTC-Zeiten führen (7:00/8:00 UTC).

Wenn man die Serie auflöst und in Einzeltermine umwandelt geht's natürlich, aber das ist nicht Sinn einer Terminserie und führt bei Änderungen zu Problemem. Wenn man die Serie belässt dürfte die Angabe der passenden Zeitzone wesentlich einfacher und intuitiver sein, als eine komplexe Regel für das Sommer- und Winterhalbjahr oder vielleicht sogar separate Serien zu erstellen.

 

[__W__]

... an jedem letzten Mittwoch im Monat um 9:00 stattfindet würde im Sommer- und im Winterhalbjahr zu verschiedenen UTC-Zeiten führen (7:00/8:00 UTC).

Damit hast du Recht, Terminserien sind unter Android bisher noch nicht "Top zuverlässig" oder "richtig komfortabel" und das liegt unter anderem daran, dass die "Rückrechnung" auf eine Basiszeit nicht immer richtig funktioniert.
Trotzdem macht das Runterbrechen auf eine fixe "Zeitzone" Sinn, da damit Weltenbummler die "Realzeit" im Blick behalten können und es sich einfacher rechnen läßt.

Genauso gibt es immer noch Probleme mit Einzelterminen in Serien, die geändert werden (müssen), weil irgend ein Feiertag im Weg liegt.

Das Problem der Terminserien ist ja auch nicht ganz unkomplex und wenn dann noch ein Schaltjahr dazu kommt ...
Zudem ist die Beschreibung "letzter Mittwoch im Monat" für einen Computer sehr unpräzise.

Gruß __W__