Scheduling Oban jobs with timestamps with timezones

I am refactoring a scheduling service that I initially created using GenServers and Supervisors that on every hour reads the next jobs to be run from the database by parsing their scheduled time and their timezone field. I want to refactor this functionality to use Oban, but I stumbled upon the issue that the timestamps are saved in Postgres without timezone data.

I wanted to ask - is there a way to configure Oban jobs to store timezone data as well and use it for scheduling by, for instance, adding an additional field to the oban_jobs table or editing the type of the scheduled_at column? Or if there is another way to schedule Oban jobs with a timestamp in a specific timezone. Saving them in UTC is not optimal as some of them might be scheduled for a few months in the future when the DST offset is different. But timezones could theoretically change in various ways anyway.

Edit: I noticed that shifting the timezone considers the DST for the future, which I assume solves most problems. I guess the only problem then is if a timezone changes, let’s say stops using DST or changes the DST transitions, is that correct?

1 Like

There isn’t any way to change the column type for timestamps like scheduled_at. However, you can use a timezone database for Cron jobs (Oban.Plugins.Cron — Oban v2.13.4). That may not help in your circumstance, but I think you’re safe to calculate the UTC value and schedule anyhow—you’re only scheduling jobs for an hour at a time.

1 Like

Thank you for the response! Let me say first that what you have and are doing is amazing, thank you for everything!

As for the scheduling in my use case - I was thinking that we could remove the part that schedules for one hour at a time if we use Oban and just schedule everything right when it is created by adding it to a queue with the scheduled_at option. I think we’ll proceed like that, seems quite safe as it is at least when I tested a bit today. I was actually initially thinking of using the Cron plugin as you mentioned, but in the end I think it can be even simpler for our use case.

Once more, thank you very much!