Support for CRON_TZ

[Jay-zs]

Is your feature request related to a problem? Please describe.

• Cron jobs interacting with servers in non-UTC timezones, especially those affected by daylight saving time, require manual updates to cron schedules to ensure they remain operational.

Describe the solution you'd like

• There should be an option to specify the timezone against which the cron schedule will be evaluated.
• The NewCron factory can be enhanced to use the functional options pattern, allowing gofr to provide an exported option to specify the timezone, such as time.Location.

[JayGoyal96]

Hey @Umang01-hash, Can you please assign this issue to me.

[Umang01-hash]

Sure @JayGoyal96.

[Jay-zs]

@Umang01-hash , PR is up for review.

[aryanmehrotra]

@Jay-zs when same source code is running across different regions - how would you set the region for all of them?
Moreover, most cloud provider allows to set the timezone of a system when you are creating them.

I just want to understand the context of this issue, as I think this shouldn't be an app level concern as the same app can run across different regions and you can set the timezone from the infra of an instance

[JayGoyal96]

Setting the timezone at the infrastructure level is discouraged, as experts advocate for running Kubernetes services in UTC to ensure consistency and avoid issues in distributed systems.
Changing the infrastructure timezone can affect audit timestamps, causing discrepancies in logs and compliance.

For multi-region deployments, managing timezones at the application level using environment variables provides flexibility and ensures cron schedules align with regional needs, while the core process operates uniformly in UTC.
This approach reduces errors, simplifies debugging, and enhances maintainability.

Let me know your thoughts on this.

[aryanmehrotra]

How would you solve for this particular use case based on the current approach -
You have some x service running in 3 different locations - INDIA, AUSTRALIA and US.
Based on your approach you would be keeping the time zone different in all the three zones, but there are two problems

1. service running in US can still serve for user in India.
2. setting different time zones get tightly coupled.

[JayGoyal96]

@aryanmehrotra, I can't think of a use case where a cron job is needed to serve users across time zones.

To clarify the original ask: If you have a file listener cron job where the file is available at a specific time in a particular timezone (affected by daylight savings), scheduling the cron job in UTC might require adjusting for daylight savings to keep the job operational.

If we follow your suggestion of setting the timezone at the infrastructure level, time.Local will reflect that timezone in logs and audit timestamps, but that might not be necessary. Instead, having an option to evaluate the cron schedule in a specific timezone (while keeping the job running in UTC) could address this without the need for infrastructure-level changes.

To mitigate this, we eventually moved to a K8s cron job workload, which provides an option to specify the timezone for evaluating the cron schedule, instead of having the scheduler (gofr's cron table) in the code and deploying it as a Deployment workload.
Source: Kubernetes Cron Jobs

Although I advocate for the K8s CronJob workload, as it helps save costs by evicting the pod when not needed, I've seen gofr cron jobs that are aware of their Deployment nature and keep things in memory to support the next iterations. In such cases, moving to a K8s CronJob would require significant effort.