Request to support running on server local time instead of UTC time zone

[SamTeong]

Currently IDateTimeProvider is only implemented by UtcNowTimeProvider and exposes method for GetUtcNow() which is used extensively in Scheduling logic. Would it be possible to extend to support running on server local time instead?

[eXpl0it3r]

Hey Sam! 👋

The decision to use UTC everywhere was intentional and there's currently no support for other time zones.
It's a bit of a philosophical discussion whether server software should run/use something other than UTC.

I don't know what it would take to change that approach, but I think we can differentiate between two options:

• Change the final displaying of the date/time to the user
• Change the storing/handling of the date/time within Jobbr

I feel like the first option is more suited.

[SamTeong]

Ah, unfortunately, the issue we're facing is not for UI display, but rather alignment of the Jobbr scheduling with other job scheduling systems which run on CET (Central European Time) time zone. Due to Daylight Saving Time, CET can vary between UTC+1 and UTC+2.

[eXpl0it3r]

Seems the providers are registered and injected, as such it would be possible to use a different provider implementation.

The main question is, how could this be configured and where. I'm open for suggestions, if you want to think of a design.

[SamTeong]

Would it be that simple to just inject a time provider different from UtcNowTimeProvider?
IDateTimeProvider would need to be updated to expose GetNow() instead (for consistency).
DateTime.UtcNow is used in JobService, JobRunService, DefaultScheduler.
Names with UtcNow would need to be updated.
Tests would need to be modified.

[SamTeong]

As for dependency injection, there's Jobbr.Server.Builder.JobbrBuilder.Add() which can be used by end users to inject the instance type of IDateTimeProvider