3 ms·

This article about dealing with recurrence in applications was an eye-opener for me. Definitely recommend giving it a read. https://github.com/bmoeskau/Extensib

• Sander_Marechal 2y ago
  Funny how the original article's advice and your article oppose each other. - OP says to always store a timezone with each date, yours says to convert everything to UTC (I agree with OP) - OP says to generate database rows for each event, yours says to not do that (I agree with yours)
  • fendy3002 2y ago
    > OP says to always store a timezone with each date Jon Skeet talked about this once. https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/ https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a... What I take is convert everything to UTC is fine if it's historical data, even unix timestamp is fine. However for the future datetime, it's more complicated than that.
    • deleted 2y ago
      [deleted]
  • UglyToad 2y ago
    Having built recurring stuff in the past (date based with no time component, luckily for me) I think you gain a lot of usability gains for generating a row for each occurrence of the event. Inevitably the user will come back and say "oh, I want it monthly except this specific instance" or if it's a time based event "this specific one should be half an hour later". You could just store the exceptions to the rule as their own data-structure but then you need to correlate the exception to the scheduler 'tick' and if they can edit the schedule, well, you're S.O.O.L either way but I think having concrete occurrences is potentially easier to recover from.