Hangfire: Allow Recurring Tasks to be Scheduled for Local Time

Created on 4 Dec 2014  路  9Comments  路  Source: HangfireIO/Hangfire

The changes made for #160 don't work well for my use case:

My client is a smaller organization (i.e. a single time zone) which needs a batch of emails sent every night at 7:00 PM (1900h) (after their employees leave for the day) so it _should_ respect daylight savings time.

Here's my workaround for the current UTC-only limitation:

            RecurringJob.AddOrUpdate(
                "upcoming-jobs-email", 
                () => ObjectFactory.GetInstance<UpcomingJobsEmails>().Run(),
                "0 {0} * * 1-5".ToFormat(DateTime.Today.AddHours(19).ToUniversalTime().Hour)
            );

But I believe once my time zone switches in or out of DST, I'll be off by an hour until the app pool recycles (which doesn't happen normally for my server setup).

Ultimately, I'd love for there to be an option to schedule tasks for _both_ UTC and local time.

Most helpful comment

Time zones is an essential part of recurring jobs, I agree. It was a strange decision to use UTC time zone by default instead of a local one, as all other frameworks and programs do that for CRON-based launchers. Looks like I was drunk ;)

I have a simple implementation for this, now thinking about time zone identifiers on Windows and Linux machines. Since ASP.NET vNext makes great strides to support Linux as well, the fact that time zone identifiers are different on different platform should be considered. So, there are the following ways:

  • Use BCL time zones (TimeZoneInfo class) and solve issues when they are arising.
  • Use TZDB as a time zone provider. This may be accomplished with using NodaTime.

What do you think?

image

All 9 comments

Any word on this? The job needs to fire at 7:00 PM, and I'm GMT -5, so that means I have to offset the day of the week in addition to the time. It's really a bummer.

Agreed - we would love to see local time threaded throughout.

I think it makes sense to have either option because in my use case, it's part of the business rules: "At 7:00 every night (Eastern Time) send this report...."

But not everyone's rules will be like that.

Agreed! Would love to see the ability to specify a TZ for recurring task.

Time zones is an essential part of recurring jobs, I agree. It was a strange decision to use UTC time zone by default instead of a local one, as all other frameworks and programs do that for CRON-based launchers. Looks like I was drunk ;)

I have a simple implementation for this, now thinking about time zone identifiers on Windows and Linux machines. Since ASP.NET vNext makes great strides to support Linux as well, the fact that time zone identifiers are different on different platform should be considered. So, there are the following ways:

  • Use BCL time zones (TimeZoneInfo class) and solve issues when they are arising.
  • Use TZDB as a time zone provider. This may be accomplished with using NodaTime.

What do you think?

image

Love this! Thumbs up.

With this idea, how would you include the TZ in the CRON Expression?
ex: ?

  • * 1 * * * UTC
  • * 1 * * * Pacific/Honolulu

Just an additional parameter (will be simplified):

RecurringJob.AddOrUpdate(
    "Hawaiian", 
    () => Console.WriteLine("Hawaiian"),
    "29 06 * * *", 
    DateTimeZoneProviders.Tzdb.GetZoneOrNull("Pacific/Honolulu"));

TWO thumbs up now!

Was this page helpful?
0 / 5 - 0 ratings