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
3c19cf67f6
smos/smos-calendar-import
History
Tom Sydney Kerckhove 3c19cf67f6 Upgrade fuzzy-time and cursor-fuzzy-time
2024-01-18 23:09:39 +01:00
..
app First attempt at a calendar import 2020-06-11 20:36:49 +02:00
src Upgrade fuzzy-time and cursor-fuzzy-time 2024-01-18 23:09:39 +01: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 2023-11-25 14:45:38 +01:00
package.yaml Release candidate 2023-11-25 14:45:38 +01:00
README.md Refactor out an ical library 2022-12-30 14:46:27 +01:00
smos-calendar-import.cabal Release candidate 2023-11-25 14:45:38 +01: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.