Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Schedulers using different now() implementation breaks schedule_absolute() compatibility. #724

Open
Sduby22 opened this issue Nov 30, 2024 · 0 comments

Comments

@Sduby22
Copy link

Sduby22 commented Nov 30, 2024

Hi, I found that operators like

take_until_with_time(datetime)

depends on

scheduler.schedule_absolute(duetime)

to trigger, which then was implemented as

scheduler.schedule_relative(duetime - self.now)

For normal schedulers which uses default_now(), it uses datetime.now() implementation

For some schedulers like AsyncIOScheduler, it uses some event_loop internal monotonic clock for self.now, which may be far from current timestamp, and may break schedule_absolute if a user passes regular datetime.

Why is it needed to use per-scheduler now implementation? If this is the expected behavior, I think we might consider clarify the doc as such

end_time (Union[datetime, timedelta, float]) – Time to stop taking elements from the source sequence. 
If this value is less than or equal to datetime.utcnow(), the result stream will complete immediately.
                                          ^^^^^^^^^^^  scheduler.now()
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant