openerp-india team mailing list archive

["Olivier Dony \(OpenERP\)" <742439@xxxxxxxxxxxxxxxxxx>]

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