{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihhdswfjvlhcannfwyrmcbhziirrc7ftsf6vzgk3n2zqo3e72665u",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mhqfxnxmtjk2"
  },
  "path": "/t/rfc-sibyl-time-series-analysis-in-haskell/13823?page=2#post_22",
  "publishedAt": "2026-03-23T07:10:26.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "I think it is totally okay to limit the scope of Sybil to regularly-spaced time sampling, keeping the time type abstract as you did, but one should be more explicit about it. Especially when the forecasting algorithms make that assumption. Perhaps functions making this assumption could reside in a separate module.\n\nmchav:\n\n> Intervals, while useful and interesting, seem like they should be out of scope for an initial implementation.\n\nThis will quickly come into consideration once you start thinking about slices of data frames (give me all data between two points in time, all data of last month etc.), when plotting data properly, when interpolating data.\n\nmchav:\n\n> Local time isn’t a great choice. UTC Time would be better.\n\nI agree. But how often do you come across a data set that has ISO-8601 time stamps? Excel knows only local time, for example. Some older databases, too. Quite often, time series are published with `LocalTime` time stamps with an implicit assumption of a certain time zone, which could even include daylight savings time (DST). Hence my general approach is to convert everything to UTC, which in case of DST can only be a heuristic. However, I agree that there ought to be a separate package for local time-to-UTC conversion.",
  "title": "[RFC] Sibyl: Time Series Analysis in Haskell"
}