Dates are in UTC time zone.

[rzhidalgo@yahoo.com]

We are in the Pacific time zone, and the creation and expiration dates seem to be in UTC-8 time zone. The times are 8 hours ahead of our local time.

[Ryan J Ollos]

The code uses datetime.now(utc) on line 103. I think you can replace that with to_datetime(None):

from trac.util.datefmt import to_datetime

...

if notice['expiration'] == -1 or notice['expires'] >= to_datetime(None):

​Here is the relevant source code.

[Roberto Longobardi]

Hi guys, and thanks rjollos as always for your help :D

I just happened to have released a new version of this plugin following this request (come directly by email), to support local timezones.

Actually my solution was not to use to_datetime(None) as you suggest, I'm not very skilled in python, but to rely on ​http://labix.org/python-dateutil.

Rjollos, would you take a look at the modified code and see if it's ok? (I didn't release the source on SVN for this plugin (too lazy ;-), but as a zip file. Maybe I'll do it, to simplify code reviews. BTW, if you would like to be added as a developer just tell me.)

Let me know. Ciao, Roberto

[Ryan J Ollos]

Replying to seccanj:

Rjollos, would you take a look at the modified code and see if it's ok? (I didn't release the source on SVN for this plugin (too lazy ;-), but as a zip file. Maybe I'll do it, to simplify code reviews. BTW, if you would like to be added as a developer just tell me.)

Where is the modified code at? All I've found so far is the ​Git repository on SF. I'd be happy to help out with the plugin if you want to add me as a developer. My SourceForge username is also rjollos. Thanks!

Btw, I think the advantage of using to_datetime(None) from the Trac core is that the localtime will be taken from the user's preference. The user's timezone preference will default to default_timezone in trac.ini (​t:TracIni#trac-section). If the default_timezone hasn't been specified in trac.ini, then the server's timezone setting will be used. Well, at least I think that is how it works. I'd double check that what I stated here is correct before pushing a patch.

[Ryan J Ollos]

Replying to Ryan J Ollos:

Replying to seccanj:

Rjollos, would you take a look at the modified code and see if it's ok? (I didn't release the source on SVN for this plugin (too lazy ;-), but as a zip file. Maybe I'll do it, to simplify code reviews. BTW, if you would like to be added as a developer just tell me.)

Where is the modified code at? All I've found so far is the ​Git repository on SF. I'd be happy to help out with the plugin if you want to add me as a developer. My SourceForge username is also rjollos. Thanks!

I'd still be interested in contributing if you were willing to add me as a developer.

How would you feel about putting the source code in SVN, either on SF or here at trac-hacks.org? That would make it easier to collaboratively develop.

Do you have Trac versions that you are currently supporting? If you don't particularly care about Trac 0.12, I like to target Trac >= 1.0, or >= 1.2.