From 7e130f238413dd72b89670a9bc5cc9a7e5cbb68c Mon Sep 17 00:00:00 2001 From: evanstjabadi Date: Sun, 18 Dec 2022 09:19:26 +0200 Subject: fix(docs): minor spelling edits in userguide --- docs/userguide.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/userguide.rst b/docs/userguide.rst index 5d9cc04..9bc2073 100644 --- a/docs/userguide.rst +++ b/docs/userguide.rst @@ -50,7 +50,7 @@ processing to other scheduler instances running elsewhere. Basic concepts / glossary ========================= -These are the basic components and concepts of APScheduler whixh will be referenced +These are the basic components and concepts of APScheduler which will be referenced later in this guide. A *task* encapsulates a Python function and a number of configuration parameters. They @@ -300,7 +300,7 @@ In most cases, when a scheduler processes a schedule, it queues a new job using run time currently marked for the schedule. Then it updates the next run time using the schedule's trigger and releases the schedule back to the data store. But sometimes a situation occurs where the schedule did not get processed often or quickly enough, and -one or more next run times produced by the trigger are actually in the past. +one or more next run times produced by the trigger are actually in the past. In a situation like that, the scheduler needs to decide what to do: to queue a job for every run time produced, or to *coalesce* them all into a single job, effectively just @@ -317,7 +317,7 @@ The possible values are: run times The biggest difference between the first two options is how the designated run time, and -by extension, the starting deadline is for the job is selected. With the first option, +by extension, the starting deadline for the job is selected. With the first option, the job is less likely to be skipped due to being started late since the latest of all the collected run times is used for the deadline calculation. -- cgit v1.2.1