request.now is set each time a new request comes in and is specific to that request. When you start the shell, there are no requests coming in to the shell -- so request.now is set when the shell is first started, and there's nothing to change it after that. The shell basically gives you a web2py environment in the context of a single request.
Anthony On Tuesday, October 4, 2011 7:08:26 PM UTC-4, TheSweetlink wrote: > > Truly bizarre. > > When I put timetest() in default.py and test it it works a treat. > > output: > 2011-10-04 18:40:07.876602 ## 2011-10-04 18:40:07.894192 > > > If I run from the commandline (importing models and such as I normally > do to test things): > > print request.now, datetime.datetime.now() > > produces: > 2011-10-04 18:36:04.232022 2011-10-04 18:41:02.857936 > > I just learned that request.now doesn't even change anymore when run > from cli but datetime.datetime.now() does. request.now just stays at > the time I started web2py from the cli. > > In the past I have done the following to test small pieces of my code > /my_path_to_web2py/web2py.py -S init -M -N > > Am I doing something wrong? > > request.now used to be now now (and it is in the browser apparently) > like in Spaceballs but clearly I've past then...just now. > > This is all in an effort to poll a controller function to check for > new messages and refresh a component when there is a newer timestamp > compared to last message received. The problem is my newly inserted > messages kept showing up as in the past so the polling won't trigger a > refresh. > > Preferrably, I could use Redis' pubsub, subscribe to a channel and > publish a message to signal refresh of the component. > > I made a bit of progress with Redis' pubsub but cannot figure out how > to completely render the page and then start the pubsub's > listener.next(). > > It is a blocking call that holds everything up waiting for new > messages on the subscribed channel so I figured polling is the way to > go for now. > > I just remembered another possibility that it could be VM related. > Guest is Centos 6 and I recall 5.x had some really screwy timing > issues. I'll look into that. > > Grumblegrumble, back to the drawing board. > > Thanks for your help pbreit. > > -David > > > On Oct 4, 5:25 pm, pbreit <[email protected]> wrote: > > Is it isolated something like this? > > > > def timetest(): > > import datetime > > return '%s ## %s' % (request.now, datetime.datetime.now()) > > > > 2011-10-04 14:23:41.505797 ## 2011-10-04 14:23:41.536510
