Closed hlascelles closed 6 years ago
Hello,
yes, the handling of timezones is planned. Yes, rufus-scheduler 3.x scheduling should be understood by rufus-scheduler 4.x.
I will work on that since you need it. Thanks for the feedback.
Hello @hlascelles
could you please tell me if the changes ending in https://github.com/floraison/fugit/commit/ea7f47a257bd1b0d285c473023e6b721cd1e241b are satisfying for you.
I make sure to store the zone given at the end of the cron line, #next_time
and #previous_time
calculate in that zone but make sure to return a EtOrbi::EoTime
result instance in the "start" zone. For example if your cron is specified for Moscow but your Ruby process is set to Los Angeles, the transitions will be computed for Moscow but the result will be translated to Los Angeles time.
When we have something that works correctly, I will release a new version of fugit.
Thanks in advance.
Builds are passing: https://github.com/hlascelles/que-scheduler/pull/8
Looks good. Thanks!
fugit 1.1.0 just released. We have to give some time for the propagation in the Rubygems mirrors. Please tell me if there is anything wrong with this new version.
Closing.
Thanks again!
Is the handling of timezones in fugit cron lines planned? (ie, will rufus-scheduler 4.x be compatible with rufus-scheduler 3.x?).
Background: que-scheduler uses fugit to parse cron lines. It was hoped the config file it would mirror the one for resque-scheduler. However fugit doesn't seem to handle timezones. This means the config for que-scheduler throws errors.
I could move to using rufus-scheduler 3.x in que-scheduler for now, but didn't want to add features which would not be forwardly compatible.