c2c-oerpscenario team mailing list archive

["Azazahmed Saiyed \(OpenERP\)" <742439@xxxxxxxxxxxxxxxxxx>]

** Changed in: openobject-server
   Importance: Undecided => Wishlist

** Changed in: openobject-server
       Status: New => Confirmed

** Changed in: openobject-server
     Assignee: (unassigned) => OpenERP's Framework R&D (openerp-dev-framework)

-- 
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
https://bugs.launchpad.net/bugs/742439

Title:
  Timezone as three-letter-acronym is ambigous, should be ISO
  standardized

Status in OpenERP Server:
  Confirmed

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.