This was solved in OpenERP 6.1 as the server will always work with pure UTC
datetime values, with timezone conversions are performed on client-side using
whatever timezone is configured:
- for the web client, using the browser's timezone, i.e. the OS timezone
- for the GTK client, using the timezone set in the user preferences, which can
be set to an unambiguous value based on the location, such as
"Eurpose/Brussels".
The common/timezone_get() method of the server will always return "UTC"
now, which is unambiguous as well.
Thanks for reporting!
** Changed in: openobject-server
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of OpenERP
Indian Team, which is subscribed to OpenERP Server.
https://bugs.launchpad.net/bugs/742439
Title:
Timezone as three-letter-acronym is ambigous, should be ISO
standardized
Status in OpenERP Server:
Fix Released
Bug description:
We encountered a bug while writing Date via xmlrpc from Java to OpenERP, and
found that it looks like
https://bugs.launchpad.net/openobject-server/+bug/397294 is our problem.
There, it's suggested to use String instead of DateTime. I found the
DEFAULT_SERVER_DATETIME_FORMAT constant in server/tools/misc.py, and I use a
request to common/timezone_get to get the timezone.
But that is text, like "CET".
I looked for getting a numeric timezone for easier calculations, or at list
of timezone identifiers, and found the following information:
The traditional alphabetical time zone names and their abbreviations are not
standardized. There are over 300 of them, with many time zones having multiple
names. Also, the abbreviations do not always have 3 letters.
ISO-8601, the norm for date and time zone formats, does not use names and
abbrevations at all. The ISO format indicates the geographical position by
numerical combinations.
Time zone are written as offset from UTC in the format ±[hh]:[mm], ±[hh][mm],
or ±[hh]. So if the time being described is one hour ahead of UTC (such as the
time in Berlin during the winter), the zone designator would be "+01:00",
"+0100", or simply "+01".
(Java Doc:) For compatibility with JDK 1.1.x, some other three-letter
time zone IDs (such as "PST", "CTT", "AST") are also supported.
However, their use is deprecated because the same abbreviation is
often used for multiple time zones (for example, "CST" could be U.S.
"Central Standard Time" and "China Standard Time"), and the Java
platform can then only recognize one of them.
A xmlrpc call to common/timezone_get returns pythons time.tzname[0], the name
of the local non-DST timezone.
As noted above, this is not standardized and ambigous.
I propose adding (for backward compatibility) a second return value, pythons
time.timezone: The offset of the local (non-DST) timezone, in seconds west of
UTC (negative in most of Western Europe, positive in the US, zero in the UK).
This is easily compatible to ISO-8601 syntax and can directly be used for
calculations.
To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-server/+bug/742439/+subscriptions
_______________________________________________
Mailing list: https://launchpad.net/~openerp-india
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openerp-india
More help : https://help.launchpad.net/ListHelp
