NorfairKing/smos
1
1
Fork 0
mirror of https://github.com/NorfairKing/smos.git synced 2024-10-03 19:57:10 +03:00
Code Issues Projects Releases Wiki Activity
release
smos/smos-calendar-import
History
Tom Sydney Kerckhove 8c7f97b3ab Release candidate
2024-05-14 14:15:20 +02:00
..
app First attempt at a calendar import 2020-06-11 20:36:49 +02:00
src Weeder 2024-04-15 18:21:57 +02:00
test update inputs 2023-11-22 12:53:46 +01:00
test_resources Update ical dependency 2023-10-29 15:24:02 +01:00
.gitignore build strictly, just to be sure 2021-05-04 09:39:52 +02:00
default.nix Release candidate 2024-05-14 14:15:20 +02:00
package.yaml Release candidate 2024-05-14 14:15:20 +02:00
README.md Refactor out an ical library 2022-12-30 14:46:27 +01:00
smos-calendar-import.cabal Release candidate 2024-05-14 14:15:20 +02:00

README.md

The Smos Calendar Import tool

See https://docs.smos.online/smos-calendar-import

Hacking on this:

The workflow goes:

ICal  -[ pick ]-> RecurringEvents       ; Pick the relevant parts out of events
      -[ recur ]-> UnresolvedEvents     ; Recur the events
      -[ resolveZones ]-> [UTCEvents]   ; Resolve the events' timestamps' timezones to utc
      -[ resolveLocal ]-> [Events]      ; Resolve the events' timestamps' timezones to local time
      -[ filter ]-> [Events]            ; Filter the relevant events (time-wise)
      -[ render ]-> SmosFile            ; Render a smos file

Known issues (that still need to be resolved)

The recurrence implementation operates on local times, and is unaware of timezone resolution. However, this can go wrong around summer/winter-time transitions because this can introduce duplicates that are counted towards the Count (while they shouldn't.)

We judged this to be a tiny problem because:

  1. it only occurs on timezone changes
  2. it only occurs on events that recur multiple times in a day AND have a 'COUNT' rule part.