fix: shifting days across daylight savings boundaries

[gf3]

see #304 for context

the tests pass, however i'm really not sure if this will break existing functionality

[Matsa59]

And sorry for you but the fix didn't work with the following input :/

      ~Y[2024-03-08 02:00:00 America/Montreal]
      |> Cocktail.schedule()
      |> Schedule.add_recurrence_rule(:daily)
      |> Cocktail.Schedule.occurrences()
      |> Enum.take(3)

[gf3]

@Matsa59 ahh, it seems to be the time. i was testing with 00:00:00 but it fails in your scenario with 02:00:00

[Matsa59]

I fix the issue on #306, try it on your project to be sure everything is ok

[Matsa59]

I don't know If it's ok to share this here (if not I can remove this comment at every moment)

I develop a library that works the same way as cocktail (for validations) except we build the lib considering timezone from the beginning.

https://hexdocs.pm/ex_cycle

Obvs cocktail manage more thing (like rule to string / from string) that we don't handle for the moment. Maybe it could help people facing on the timezone / DST problems

---

What we do differently (if It could help here):

• we cast to timezone as a validation at the end of the generation
• we don't bump 1ms to generate the next one occurence (we simply force apply the first rule)
• we have a state that evolve during validations apply
• For every validations, we have a valid? and a next functions

---

I prefer elixir to have less lib instead of having library that does the same things. So I guess we'll have to discute one day which one will survive et which one must be removed (it could be mine once cocktail fix DST problems)

[gf3]

@Matsa59 awesome, i'll have a look!