On 08/21/2012 06:04 PM, Cristian Salamea (Gnuthink) wrote:
> If system works with with UTC, here in Ecuador with GMT -5 when try to
> use:
>
>>>> from time import strftime
>>>> strftime('%H:%M:%S')
This will give you the current UTC time, and it is by design in 6.1.
There is one golden rule for datetime fields in 6.1 addons code:
"ALWAYS work in UTC - compute in UTC - save in UTC"
The UTC values will be properly converted to local time when the result is
diplayed in a client-side form.
> gets +5 hours, i find out this and system force python to use UTC,
> timezone in Web UI is set to America/Guayaquil but is not ok in server.
If for some reason you *really* want to use the local time (it is probably a
mistake!) you can use fields.datetime.context_timestamp. Have a look at the
docstring.
PS: You're posting this on a bug that talks about pure date fields, but your
sample code uses the time only... this is pretty weird. For *date* fields
fields the logic is completely different, I'm afraid you're mixing different
issues.
This is complicated stuff, you should read very carefully the explanations on
this bug and on related bugs to make sure you understand how it works for the
various types of fields.
On 08/21/2012 06:04 PM, Cristian Salamea (Gnuthink) wrote: '%H:%M: %S')
> If system works with with UTC, here in Ecuador with GMT -5 when try to
> use:
>
>>>> from time import strftime
>>>> strftime(
This will give you the current UTC time, and it is by design in 6.1.
There is one golden rule for datetime fields in 6.1 addons code:
"ALWAYS work in UTC - compute in UTC - save in UTC"
The UTC values will be properly converted to local time when the result is
diplayed in a client-side form.
> gets +5 hours, i find out this and system force python to use UTC,
> timezone in Web UI is set to America/Guayaquil but is not ok in server.
If for some reason you *really* want to use the local time (it is probably a datetime. context_ timestamp. Have a look at the
mistake!) you can use fields.
docstring.
PS: You're posting this on a bug that talks about pure date fields, but your
sample code uses the time only... this is pretty weird. For *date* fields
fields the logic is completely different, I'm afraid you're mixing different
issues.
This is complicated stuff, you should read very carefully the explanations on
this bug and on related bugs to make sure you understand how it works for the
various types of fields.