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.
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:
TimeZoneInfo class) and solve issues when they are arising.NodaTime.What do you think?

Love this! Thumbs up.
With this idea, how would you include the TZ in the CRON Expression?
ex: ?
Just an additional parameter (will be simplified):
RecurringJob.AddOrUpdate(
"Hawaiian",
() => Console.WriteLine("Hawaiian"),
"29 06 * * *",
DateTimeZoneProviders.Tzdb.GetZoneOrNull("Pacific/Honolulu"));
TWO thumbs up now!
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:
TimeZoneInfoclass) and solve issues when they are arising.NodaTime.What do you think?