search

Miksus / rocketry

Modern scheduling library for Python
https://rocketry.readthedocs.io
MIT License
3.25k stars 105 forks source link

ENH Optionally specify timezone #113

Open Miksus opened 1 year ago

Miksus commented 1 year ago

Is your feature request related to a problem? Please describe. Some people would like to use Rocketry with other timezones. For example, if the code is developed on a timezone +2 and the machine where it is run is at timezone +0, there could be problems. Running the application in the developer's machine vs in the production environment would result tasks to be run at different times between these environments.

For example, there is a task scheduled to run at 10:00. If the developer runs the application, the task will be run 10:00 in his/her local time but it would be 08:00 in the production server's time. The development environment probably should run tasks at the same universal times as the production environment.

Describe the solution you'd like Optionally specify a timezone in the session object. Probably also requires the time measurement will be done in the same function throughout the library.

Single function for measurement has the added benefit that one could override it in order to build unit tests: check a task is indeed runned when the current time is 10:00, for example.

Describe alternatives you've considered One could override the time.time but that has added problems. Possibly no feasible alternatives without core changes.

Additional context The measurement of time is done using time.time (instead of datetime.datetime.now) in order to work together with logging (as it uses time.time). There is a bug in Python that datetime.datetime.now and time.time do rounding differently causing problems in quickly executed tasks if datetime.datetime.now was used.

The logs store the timestamps in timezone agnostic way (using Unix epoch).

nabhosal commented 1 year ago

Any tentative date for the fixes?

Miksus commented 1 year ago

Most likely in the next release. This is useful for me as well as the unit testing is slightly trickly for the logs (I'm on different timezone than the Github Actions).

Cannot promise a date though. I'm currently working on the multilaunch/ignore alive check, then I'm fixing one bug related to grouper (haven't yet made the ticket) and then I'm planning to do this. Of course, the timelines depends on how much I have free time in the upcoming weeks.

Miksus commented 1 year ago

FYI: I'm currently working on this (#147). Still facing some issues of how to maintain the statelessness of the conditions while providing the timezone but I think those can be handled.

I think I'll produce the next release after that's done. There will also be an option to override the function for measuring time (useful mostly in testing but really handy in that).