NorfairKing/smos
1
1
Fork 0
mirror of https://github.com/NorfairKing/smos.git synced 2024-10-04 04:07:15 +03:00
Code Issues Projects Releases Wiki Activity
f7c2287838
smos/smos-calendar-import
History
Tom Sydney Kerckhove f7c2287838 release candidate
2023-09-12 15:35:00 +02:00
..
app First attempt at a calendar import 2020-06-11 20:36:49 +02:00
src Upgrade to lts 20.23 and nixos 23.05 2023-06-12 14:42:58 +02:00
test Upgrade dependencies 2023-04-28 13:38:41 +02:00
test_resources Upgrade dependencies 2023-04-28 13:38:41 +02:00
.gitignore build strictly, just to be sure 2021-05-04 09:39:52 +02:00
default.nix release candidate 2023-09-12 15:35:00 +02:00
package.yaml release candidate 2023-09-12 15:35:00 +02:00
README.md Refactor out an ical library 2022-12-30 14:46:27 +01:00
smos-calendar-import.cabal release candidate 2023-09-12 15:35:00 +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.