Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Date: Fri, 07 Jun 2013 01:49:55 +0100
From: MRAB <python@mrabarnett.plus.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: trigger at TDM/2 only
References: <46d8c42f-fdfd-49a5-96e8-ec53d5e599d5@googlegroups.com>
In-Reply-To: <46d8c42f-fdfd-49a5-96e8-ec53d5e599d5@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Reply-To: python-list@python.org
Newsgroups: comp.lang.python
Message-ID: <mailman.2832.1370566146.3114.python-list@python.org>
Lines: 52
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:47288

On 07/06/2013 01:03, cerr wrote:
> Hi,
>
> I have a process that I can trigger only at a certain time. Assume I have a TDM period of 10min, that means, I can only fire my trigger at the 5th minute of every 10min cycle i.e. at XX:05, XX:15, XX:25... For hat I came up with following algorithm which oly leaves the waiting while loop if minute % TDM/2 is 0 but not if minute % TDM is 0:
> 	min = datetime.datetime.now().timetuple().tm_hour*60 + datetime.datetime.now().timetuple().tm_min
> 	while not (min%tdm_timeslot != 0 ^ min%(int(tdm_timeslot/2)) != 0):
> 		time.sleep(10)
> 		logger.debug("WAIT "+str(datetime.datetime.now().timetuple().tm_hour*60 + datetime.datetime.now().timetuple().tm_min))
> 		logger.debug(str(min%(int(tdm_timeslot/2)))+" - "+str(min%tdm_timeslot))
> 		min = datetime.datetime.now().timetuple().tm_hour*60 + datetime.datetime.now().timetuple().tm_min
> 	logger.debug("RUN UPDATE CHECK...")
>
> But weird enough, the output I get is something like this:
> I would expect my while to exit the loop as soon as the minute turns 1435... why is it staying in? What am I doing wrong here?
>
> WAIT 1434
> 3 - 3
> WAIT 1434
> 4 - 4
> WAIT 1434
> 4 - 4
> WAIT 1434
> 4 - 4
> WAIT 1434
> 4 - 4
> WAIT 1434
> 4 - 4
> WAIT 1435
> 4 - 4
> WAIT 1435
> 0 - 5
> WAIT 1435
> 0 - 5
> WAIT 1435
> 0 - 5
> WAIT 1435
> 0 - 5
> WAIT 1435
> 0 - 5
> WAIT 1436
> 0 - 5
> RUN UPDATE CHECK...
>
Possibly it's due to operator precedence. The bitwise operators &, |
and ^ have a higher precedence than comparisons such as !=.

A better condition might be:

     min % tdm_timeslot != tdm_timeslot // 2

or, better yet, work out how long before the next trigger time and then
sleep until then.