Out of curiosity isn’t the focus placed on the AM and PM so that no matter how large a number before the focus is the start time will be determined by AM or PM?

 

Also, I plan on creating some more clock chimes.

 

 ******

Jesus says, follow me and I'll help you through the rough spots.

the world says, hey come with me. My way is broad and easy. So what if you get crap on your shoes. You can always wash it off, can't you!                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           Sent from Mail for Windows 10

 

From: Abdel
Sent: Thursday, August 29, 2019 3:28 PM
To: nvda@nvda.groups.io; nvda-addons@nvda-addons.groups.io
Subject: [nvda] Clock-19.09-dev #AddonTesting

 

Hi everybody,

 

I am Abdel, a collaborator for the add-on Clock and calendar.

 

Someone reported the following bug when using quiet hours:

 

If the start time is greater than the end time, the duration of the

quiet hours does not arrive until the end time.

 

In principle, it must be the next day that must be automatically chosen

through an internal code.

 

This code is in the timeInRange function, defined in the dtfunctions module.

 

This function has been corrected as follows, to fix the bug:

 

> def timeInRange(startTime, endTime, checkTime, use24hour=False):

>     """

>     A function that can be used to check whether the time range

> received as a parameter does not match a specific time.

>     @param startTime: The start time in the range.

>     @type startTime: basestring.

>     @param endTime: The end time in the range.

>     @type endTime: basestring.

>     @param checkTime: The time that will allow for the verification.

>     @type checkTime: basestring.

>     @param use24hour: optional: A boolean to determine whether the

> specified times format are 24-hour format or not.

>     @type use24hours: boolean.

>     @returns: A Boolean corresponding to the verification.

>     @rtype: boolean.

>     """

>     start=parseTime(startTime, use24hour)

>     end=parseTime(endTime, use24hour)

>     check=parseTime(checkTime, use24hour)

>     if end<start:

>         end+=timedelta(days=1)

>         if check < start:

>             check+=timedelta(days=1)

>     return start<=check<end

 

 

The 19.09-dev version of the add-on is downloadable here, it is also

available by clicking on the "development version" link on the community

site, as well as with addonUpdater, in the dev channel:

 

> http://cyber25.free.fr/nvda-addons/clock-19.09-dev.nvda-addon

 

 

It will remain in development version during a period of 2 weeks.

 

Thanks in advance for confirming me if the bug persists or not.

 

Kind regards,

Abdel.