Sidekiq: Configurable timezone support for Periodic Jobs

[pabloh]

I need to set the runtime for the backgroud jobs in UTC but the since sidekiq-ent gem only supports local time, and on our app is 'America/Los Angeles' is not possible for me.
I could translate the time from UTC to LA time, but I'm worried about DST, since I'm not sure if during the transition some tasks could be duplicated or even worse, lost entirely.

Also I can't change the TZ ENV variable without affecting the behavior of other parts of the application that rely on the current value, so that's not an option either.

It think there should be a new available option to set a separate timezone on each individual crontab expression or at the very least a single one for all the definitions under config.periodic do ... end. For a paid solution it seems very reasonable to support different TZs or at least UTC given most of the similar open source projects out there provide some version of this feature.

[mperham]

I think it's simple to support something like this:

mgr.register('0 * * * *', "SomeClass") # what we have today
mgr.register('0 * * * *', "SomeClass", tz: Time.zone) # currently active timezone in Rails
mgr.register('0 * * * *', "SomeClass", tz: ActiveSupport::TimeZone.new("Kathmandu")) # specific TZ for this job

Alternatively we could do something like this and all jobs would inherit it:

mgr.time_zone = ActiveSupport::TimeZone.new("Kathmandu")
mgr.register('0 * * * *', "SomeClass")

The former is more flexible but more verbose.

[mperham]

The issue I have with this request is more theoretical: it's more complex to mentally debug cron issues when you have multiple timezones in play. I try to provide APIs which make it easy to do the simple thing and hard to do the complex thing and this goes against that ethos somewhat. That said, I think you have a reasonable edge case and real production systems sometimes have to be pragmatic and not dogmatic.

[pabloh]

I think it's simple to support something like this:

mgr.register('0 * * * *', "SomeClass") # what we have today
mgr.register('0 * * * *', "SomeClass", tz: Time.zone) # currently active timezone in Rails
mgr.register('0 * * * *', "SomeClass", tz: ActiveSupport::TimeZone.new("Kathmandu")) # specific TZ for this job

Alternatively we could do something like this and all jobs would inherit it:

mgr.time_zone = ActiveSupport::TimeZone.new("Kathmandu")
mgr.register('0 * * * *', "SomeClass")

The former is more flexible but more verbose.

Thank you for the quick answer.

I think both options are good, a third possibility could to do like the clockwork gem and have mgr.time_zone = tz as the default TZ for the scheduler, and then be able to override it on each individual job using mgr.register('0 * * * *', "SomeClass", tz: other_timezone), that would allow even more flexibility.

All 3 possibilities work for me and I would be more than happy to have just the simpler one. I'm not sure which one you prefer for the API, since other people may have more complex needs than I do so possibly the clockwork strategy is best, but as you said before, you still need to balance pragmatism and idiosyncrasy.

[mperham]

Ok, I did both:

Sidekiq.configure_server do |config|
  config.periodic do |mgr|
    # like today, local timezone
    mgr.register("* 4 * * *", "LocalWorker") # 4AM system time

    # per-job custom timezome
    # NB: tz is an option but will not be included in the job's payload
    mgr.register("* 4 * * *", "TokyoWorker", tz: ActiveSupport::TimeZone.new("Tokyo"))

    # "global" custom timezome, will affect any further registered jobs
    mgr.tz = ActiveSupport::TimeZone.new("Kathmandu")
    mgr.register("* 4 * * *", "KathmanduWorker") # 4AM in Kathmandu
    mgr.register("* 5 * * *", "KathmanduWorker") # 5AM in Kathmandu

I don't have an ETA for release but it wouldn't surprise me if this doesn't ship until 2021.

[pabloh]

Ok, I did both:

Sidekiq.configure_server do |config|
  config.periodic do |mgr|
    # like today, local timezone
    mgr.register("* 4 * * *", "LocalWorker") # 4AM system time

    # per-job custom timezome
    # NB: tz is an option but will not be included in the job's payload
    mgr.register("* 4 * * *", "TokyoWorker", tz: ActiveSupport::TimeZone.new("Tokyo"))

    # "global" custom timezome, will affect any further registered jobs
    mgr.tz = ActiveSupport::TimeZone.new("Kathmandu")
    mgr.register("* 4 * * *", "KathmanduWorker") # 4AM in Kathmandu
    mgr.register("* 5 * * *", "KathmanduWorker") # 5AM in Kathmandu

I don't have an ETA for release but it wouldn't surprise me if this doesn't ship until 2021.

Thanks a lot!.
Although that's quite a wait until 2021!, why do you think It should take much?

[mperham]

Unless there is a major bugfix, I prefer to release on a slow, regular schedule (e.g. quarterly) rather than after every significant change. Last release, 2.2.0, was only three weeks ago.

[BrVer]

@mperham, sorry but where do I find the changelog for the sidekiq-ent to see when the change is live?

[mperham]

It’s a markdown file in the root of the repo.

On Tue, Jan 26, 2021 at 08:07 Dmitry Vlasov [e-mail]
wrote:

@mperham https://github.com/mperham, sorry but where do I find the
changelog for the sidekiq-ent to see when the change is live?

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/mperham/sidekiq/issues/4749#issuecomment-767648025,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAAWX7GEAP3ZLRD2QAIN5TS33SDVANCNFSM4UDE5JQA
.