[Plone-Users] TZ environment variable not used in runzope.py

[Dylan Jay]

Hi,

I finally found a fix to my timezone issues.
Background:
There is a long standing bug where linux uses EST for Australian
Eastern Standard Time which confuses python and therefore zopes
DateTime.
I've fixed this in the past using a patch that replaces the EST
definition in DateTime however that stopped working recently just for
the modified date in the document_byline viewlet.
Turns out the ModificationDate() in ExtensibileMetadata does some of
its own work to cache the current timezone and the ZAUTZ patch doesn't
help.

Someone pointed out this great tip which is a much cleaner fix and
should have fixed the problem.

[instance]
recipe = plone.recipe.zope2instance
...
environment-vars =
#http://docs.python.org/library/time.html : std offset [dst [offset
[,start[/time], end[/time]]]]
TZ AEST-10AEDT-11,M10.5.0,M3.5.0

This will fix pythons time functions to be the correct timezone (and
give me control over ever changing dst start and end dates).

Now the weird bit.

The TZ environment variable seems to be only used depending on how
zope is started.
I normally use supervisor

[supervisor]
recipe=collective.recipe.supervisor
programs=
10 instance ${buildout:directory}/bin/instance [console] true $
{users:zope}

Will work, but

[supervisor]
recipe=collective.recipe.supervisor
programs=
10 instance ${instance:location}/bin/runzope true ${users:zope}

which is the normal way you run zope from supervisor, won't. This
won't seem to use the TZ environment variable.
This took a bit to debug so I thought I would document it here.
Anyone know what might cause this so I can submit a bug to right place?

---
Dylan Jay, Plone Solutions Manager
www.pretaweb.com
tel:+61299552830
mob:+61421477460
skype:dylan_jay

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Plone-Users mailing list
Plone...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plone-users

[David Glick]

> Will work, but
>
> [supervisor]
> recipe=collective.recipe.supervisor
> programs=
> 10 instance ${instance:location}/bin/runzope true ${users:zope}
>
> which is the normal way you run zope from supervisor, won't. This
> won't seem to use the TZ environment variable.
> This took a bit to debug so I thought I would document it here.
> Anyone know what might cause this so I can submit a bug to right place?
>

bin/instance runs a control script from plone.recipe.zope2instance which
ends up invoking Zope in a separate process via the
${instance:location}/bin/runzope shell script. Unfortunately this second
process doesn't share the environment you are setting using the
environment-vars setting, which only affects the bin/instance script.

Try setting your environment var via zope.conf instead. e.g. add to
your buildout something like:

[instance]
...
zope-conf-additional =
<environment>
TZ AEST-10AEDT-11,M10.5.0,M3.5.0
</environment>

David

--
David Glick
Web Developer
Groundwire
206.286.1235x32
david...@groundwire.org
http://groundwire.org

ONE/Northwest is now Groundwire!

[Dylan Jay]

Dylan Jay
Technical solution manager
PretaWeb 99552830

On 31/12/2009, at 3:22 PM, "David Glick" <david...@groundwire.org>
wrote:

>
>> Will work, but
>>
>> [supervisor]
>> recipe=collective.recipe.supervisor
>> programs=
>> 10 instance ${instance:location}/bin/runzope true ${users:zope}
>>
>> which is the normal way you run zope from supervisor, won't. This
>> won't seem to use the TZ environment variable.
>> This took a bit to debug so I thought I would document it here.
>> Anyone know what might cause this so I can submit a bug to right
>> place?
>>
> bin/instance runs a control script from plone.recipe.zope2instance
> which ends up invoking Zope in a separate process via the $
> {instance:location}/bin/runzope shell script. Unfortunately this
> second process doesn't share the environment you are setting using
> the environment-vars setting, which only affects the bin/instance
> script.
>
> Try setting your environment var via zope.conf instead. e.g. add to
> your buildout something like:
>
> [instance]
> ...
> zope-conf-additional =
> <environment>
> TZ AEST-10AEDT-11,M10.5.0,M3.5.0
> </environment>
>

Bin/instance is the one that works and environment-vars is equiv to
your snippet above.

[David Glick]

>>>
>> bin/instance runs a control script from plone.recipe.zope2instance
>> which ends up invoking Zope in a separate process via the
>> ${instance:location}/bin/runzope shell script. Unfortunately this
>> second process doesn't share the environment you are setting using
>> the environment-vars setting, which only affects the bin/instance
>> script.
>>
>> Try setting your environment var via zope.conf instead. e.g. add to
>> your buildout something like:
>>
>> [instance]
>> ...
>> zope-conf-additional =
>> <environment>
>> TZ AEST-10AEDT-11,M10.5.0,M3.5.0
>> </environment>
>>
>
> Bin/instance is the one that works and environment-vars is equiv to
> your snippet above.

Ah, right. My explanation was wrong (it's not the case that the
environment-vars only affect bin/instance; but is the case that they
only get set when you run zope via bin/instance). But I think the
solution I suggested may still be the way to get the runzope script to
work. Did you try it?

[Dylan Jay]

On 01/01/2010, at 4:42 AM, David Glick wrote:

>
>>>>
>>> bin/instance runs a control script from plone.recipe.zope2instance
>>> which ends up invoking Zope in a separate process via the $
>>> {instance:location}/bin/runzope shell script. Unfortunately this
>>> second process doesn't share the environment you are setting using
>>> the environment-vars setting, which only affects the bin/instance
>>> script.
>>>
>>> Try setting your environment var via zope.conf instead. e.g. add
>>> to your buildout something like:
>>>
>>> [instance]
>>> ...
>>> zope-conf-additional =
>>> <environment>
>>> TZ AEST-10AEDT-11,M10.5.0,M3.5.0
>>> </environment>
>>>
>>
>> Bin/instance is the one that works and environment-vars is equiv to
>> your snippet above.
> Ah, right. My explanation was wrong (it's not the case that the
> environment-vars only affect bin/instance; but is the case that they
> only get set when you run zope via bin/instance). But I think the
> solution I suggested may still be the way to get the runzope script
> to work. Did you try it?

yeah. same behaviour. the zope2instance environment-vars param just
sets the <environment> tag in zope.conf.
weird that runzope script seems to ignore that part of zope.conf but
works for everything else. I raised a zope2 bug.

[TimmyGee]

Hey Dylan

I'm from Melbourne and have encountered the exact same problem. There
is however no bug, you just need to configure it slightly differently
to the way you're doing it.

Try the following:

environment-vars =
TZ AEST-10AEDT-11,M10.5.0,M3.5.0

Make sure that's in every zope client defined in your buildout.cfg

That should do the trick!

Cheers,

Tim

> > davidgl...@groundwire.org

> >http://groundwire.org
>
> > ONE/Northwest is now Groundwire!
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy

> Join now and get one step closer to millions of Verizon customershttp://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Plone-Users mailing list
> Plone-Us...@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/plone-users

[Matthew Wilkes]

On 2009-12-31, at 1842, David Glick wrote:

> But I think the
> solution I suggested may still be the way to get the runzope script to
> work. Did you try it?

See also:

http://www.teamrubber.com/blog/oddness-changing-time-zone-in-zope/

Matt

[Dylan Jay]

On 06/01/2010, at 1:02 AM, Matthew Wilkes wrote:

>
> On 2009-12-31, at 1842, David Glick wrote:
>
>> But I think the
>> solution I suggested may still be the way to get the runzope script
>> to
>> work. Did you try it?
>
> See also:
>
> http://www.teamrubber.com/blog/oddness-changing-time-zone-in-zope/

yep that's exactly the behaviour I observed. Thanks. The workaround I
found was the using "bin/instance console" in supervisor as suggested
in the comments.

I raised a zope2 bug but not sure if zope2 or zope2instance is to blame.

https://bugs.launchpad.net/zope2/+bug/501805

[ajung]

Using

<environment>...</environment>

is working with runzope.

No idea what the recipe is doing in your case...basically
the Zope behavior appear fine to me.

-aj

--
View this message in context: http://n2.nabble.com/TZ-environment-variable-not-used-in-runzope-py-tp4235162p4259230.html
Sent from the General Questions mailing list archive at Nabble.com.

[TimmyGee]

The way I suggested works for me

> > Plone-Us...@lists.sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/plone-users
>
> --
> View this message in context:http://n2.nabble.com/TZ-environment-variable-not-used-in-runzope-py-t...

> Sent from the General Questions mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy

> Join now and get one step closer to millions of Verizon customershttp://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Plone-Users mailing list
> Plone-Us...@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/plone-users