3 ms·

I've used a database layout that mirrored the data that can be in an ical file, which supports defining the recurrence without having to actual create each inst

I've used a database layout that mirrored the data that can be in an ical file, which supports defining the recurrence without having to actual create each instance, and supports recurrences with no end date.

withinboredom 3y ago
We went with something similar to that at one point. Our problem was we had only a few dozen ms to render thousands of recurring events. Most customers didn’t look more than a few weeks ahead (though we rendered them out decades). Using your approach would have taken too long to calculate intersections — it was our initial approach actually — but just making a simple query and rendering actual events was much faster. Optimization is the ruination of all elegance.
- ta1243 3y ago
  If you have created those decades ahead against UTC they will mostly likely be wrong unless the business wanted them recorded as UTC.
  - withinboredom 3y ago
    We didn't have any issues at all, worked for over a decade and it was super fast. I'm curious how you'd think they would be wrong?
    - ta1243 3y ago
      Because you are creating times for events you don't know what the UTC will be. if you are lucky your guesses will be right. If you created an event in 2004 for 10AM New York in 2008, you may well have created it for 1500 UTC based on predicted time in 2008. When the Energy Policy Act of 2005 passed that event would have had to change to 1400 UTC. As you didn't store the timezone you had no idea whether to change it or not. Chances are your users just ignored the problem, blamed the government rather than your poor code, or you didn't exist then, and you as an american-centric company has no idea that unpredicted unscheduled DST time changes occur all the time.
      - withinboredom 3y ago
        > Because you are creating times for events you don't know what the UTC will be. This is what settings are for. This was an enterprise application, so the timezone was set for the location of the venue, in the settings. We knew exactly what timezone to convert from/to. > if you are lucky your guesses will be right. This is software, there is never a reason to guess.
        ta1243 3y ago
        tzdata makes guesses (predictions) all the time -- every time in the future is a guess. There is no way to know that a government won't change DST dates, or even shift a country to a different timezone. Look at the whole Lebanon mess from earlier this year: If you had, at Mar 24 2023 10:00 UTC gone and created a meeting at 10AM Beirut on Mar 27th 2023 it would have been at 0800 UTC (based on the official Lebanon position that DST would not start until April 21st [0]), and you would have been wrong [1] Had you stored the datetime with location then you would have been fine. The tzdata community far know more about time than you do and make a good job at guessing what the time will be, but they still have to issue multiple updates each year due to changes from different governments. Take this update from 2021 when Fiji suspended DST for the following year https://mm.icann.org/pipermail/tz-announce/2021-October/000068.html https://mm.icann.org/pipermail/tz-announce/2021-October/0000... "Assume for now that it will return next year" It's a guess. nobody in October 2021 could say for certain that Fiji would or would not have DST in 2023. This isn't controversial. Past dates can be problematic - especially from 50+ years ago (historical data may crop up which shows that a specific location had different UTC offset which means a historical update is needed), but for future dates all predictions of UTC offsets for geographic locations are a guess [2]. Hell you can't even store the tzdata location group (say Europe/London) because in the future Scotland could decide to keep DST but England/Wales/NI/Ireland could move to BST year round. In that situation meeting at 10AM Edinburgh stored as 10AM Europe/London would be at the wrong time. That's more rare than DST date shifts, but it still happens [0] https://www.mtv.com.lb/news/local/1352516/lebanon-postpones-daylight-saving-time-adoption https://www.mtv.com.lb/news/local/1352516/lebanon-postpones-... [1] https://www.bbc.com/news/world-middle-east-65090888 https://www.bbc.com/news/world-middle-east-65090888 [2] https://codeopinion.com/just-store-utc-not-so-fast-handling-time-zones-is-complicated/ https://codeopinion.com/just-store-utc-not-so-fast-handling-...

withinboredom 3y ago

We went with something similar to that at one point. Our problem was we had only a few dozen ms to render thousands of recurring events. Most customers didn’t look more than a few weeks ahead (though we rendered them out decades). Using your approach would have taken too long to calculate intersections — it was our initial approach actually — but just making a simple query and rendering actual events was much faster. Optimization is the ruination of all elegance.

ta1243 3y ago
If you have created those decades ahead against UTC they will mostly likely be wrong unless the business wanted them recorded as UTC.
- withinboredom 3y ago
  We didn't have any issues at all, worked for over a decade and it was super fast. I'm curious how you'd think they would be wrong?
  - ta1243 3y ago
    Because you are creating times for events you don't know what the UTC will be. if you are lucky your guesses will be right. If you created an event in 2004 for 10AM New York in 2008, you may well have created it for 1500 UTC based on predicted time in 2008. When the Energy Policy Act of 2005 passed that event would have had to change to 1400 UTC. As you didn't store the timezone you had no idea whether to change it or not. Chances are your users just ignored the problem, blamed the government rather than your poor code, or you didn't exist then, and you as an american-centric company has no idea that unpredicted unscheduled DST time changes occur all the time.
    - withinboredom 3y ago
      > Because you are creating times for events you don't know what the UTC will be. This is what settings are for. This was an enterprise application, so the timezone was set for the location of the venue, in the settings. We knew exactly what timezone to convert from/to. > if you are lucky your guesses will be right. This is software, there is never a reason to guess.
      - ta1243 3y ago
        tzdata makes guesses (predictions) all the time -- every time in the future is a guess. There is no way to know that a government won't change DST dates, or even shift a country to a different timezone. Look at the whole Lebanon mess from earlier this year: If you had, at Mar 24 2023 10:00 UTC gone and created a meeting at 10AM Beirut on Mar 27th 2023 it would have been at 0800 UTC (based on the official Lebanon position that DST would not start until April 21st [0]), and you would have been wrong [1] Had you stored the datetime with location then you would have been fine. The tzdata community far know more about time than you do and make a good job at guessing what the time will be, but they still have to issue multiple updates each year due to changes from different governments. Take this update from 2021 when Fiji suspended DST for the following year https://mm.icann.org/pipermail/tz-announce/2021-October/000068.html https://mm.icann.org/pipermail/tz-announce/2021-October/0000... "Assume for now that it will return next year" It's a guess. nobody in October 2021 could say for certain that Fiji would or would not have DST in 2023. This isn't controversial. Past dates can be problematic - especially from 50+ years ago (historical data may crop up which shows that a specific location had different UTC offset which means a historical update is needed), but for future dates all predictions of UTC offsets for geographic locations are a guess [2]. Hell you can't even store the tzdata location group (say Europe/London) because in the future Scotland could decide to keep DST but England/Wales/NI/Ireland could move to BST year round. In that situation meeting at 10AM Edinburgh stored as 10AM Europe/London would be at the wrong time. That's more rare than DST date shifts, but it still happens [0] https://www.mtv.com.lb/news/local/1352516/lebanon-postpones-daylight-saving-time-adoption https://www.mtv.com.lb/news/local/1352516/lebanon-postpones-... [1] https://www.bbc.com/news/world-middle-east-65090888 https://www.bbc.com/news/world-middle-east-65090888 [2] https://codeopinion.com/just-store-utc-not-so-fast-handling-time-zones-is-complicated/ https://codeopinion.com/just-store-utc-not-so-fast-handling-...