1105: Settings updates may require a webserver restart

onkar******@gmai***** (Google Code) (Is this you? Claim this profile.)
chipx86
chipx86
March 6, 2010
1249, 1298, 1312
What version are you running?
1.0 RC1

What's the URL of the page containing the problem?


What steps will reproduce the problem?
1. Change the timezone from admin UI.
2. Post a review request (draft, not published)

What is the expected output? What do you see instead?
The dashboard should show the time the time of creation of request as per
the timezone set.

What operating system are you using? What browser?
The time shown is as per default timezone, US/Pacific I believe.
chipx86
#1 chipx86
What OS/distro are you using? What web server?

Just to make sure, did you restart your web server after upgrading Review Board?
  • +NeedInfo
#2 onkar******@gmai***** (Google Code) (Is this you? Claim this profile.)
I am using Ubuntu 8.04 and apache server. I restarted the web server multiple times.
chipx86
#3 chipx86
  • -NeedInfo
    +Confirmed
  • +Milestone-Release1.0
    +Component-Settings
chipx86
#4 chipx86
I verified that new review requests do indeed get the correct timezone. It's possible
you'll need to restart your web server after setting this option due to how the
Python processes handle timezone settings. The process setting the option will be
updated properly, but the other processes may not. We may be able to look into this
for 1.1 or 1.5, but for now, try restarting your server and seeing if that fixes
things. It seems to work for other people.

For the record, old timestamps will not be updated for the new timezone because these
are stored in the database as actual written dates/times, and are not based on the
active timezone. This is beyond our control.

At the very least, we'll want to document this.
  • -Priority-Medium
    -Milestone-Release1.0
    +Priority-Low
    +Milestone-Release1.1
    +Component-Docs
#5 onkar******@gmai***** (Google Code) (Is this you? Claim this profile.)
I do not see this issue with new review requests. I am running 1.0 final version now.
So probably this was only causing problem for old requests.
david
#6 david
  • +Settings updates may require a webserver restart
chipx86
#9 chipx86
  • -Priority-Low
    +Priority-High
chipx86
#11 chipx86
  • +Milestone-Release1.5
chipx86
#12 chipx86
This is hopefully now fixed on master (b02c63c)
  • -Confirmed
    +Fixed
  • +chipx86