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
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
Sent from Mail for Windows 10
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
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,
> 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
> @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.
> end=parseTime(endTime, use24hour)
> if end<start:
> if check < start:
> 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
It will remain in development version
during a period of 2 weeks.
Thanks in advance for confirming me if the
bug persists or not.