openerp-india team mailing list archive

[Stuart Longland <932584@xxxxxxxxxxxxxxxxxx>]

Hi Amit,
On 13/03/12 17:29, Amit Parik (OpenERP) wrote:
> Hello Stuart,
> 
> Yes, we have used a UTC format at server side for timezone. 
> I have checked your bug report as well as patch, We understand it but we can not produce it. So it can not be accepted.
> 
> That's why  please provide appropriate steps to produce it.

Okay, the problem isn't difficult to reproduce, but requires some
modifications to OpenERP to dump what it emits to Faces for resource
levelling, or some critical analysis of the scheduling output.

If the code in the project_long_term module is modified to dump a copy
of the project it passes to Faces, you'll notice that the working hours
are in local time, but the tasks are in UTC.

Faces assumes that the working hours and the tasks are in the one time
zone, in fact, it knows nothing about time zones.

So supposing the hypothetical person is running UTC+10, and works a
9:00AM to 5:00PM working week.  OpenERP is told that we work 9-5, tasks
get entered into OpenERP, the project manager clicks Schedule Tasks, and
what happens?

Faces schedules a 16 hour task to start at 0900 through to 1700, then
resume 0900 the next day.  OpenERP picks up this schedule from Faces,
leaves it *as-is*, and enters it in as if it were UTC.

And so some poor sod is forced to start their working day at 7PM, work
through midnight, and aren't allowed to go home until 3AM, all because
Faces assumes all times are local time, and OpenERP assumes all times
are UTC.

A work around is to specify the hours in UTC directly.  This could work,
however:

(1) It's unintuitive, why should an end user have to specify their
working hours as UTC when they can specify local time everywhere else?

(2) It doesn't work with the Faces library as distributed by OpenERP due
to a bug in Faces regarding shifts that span midnight -- attached to
this bug, and filed with upstream, is a fix to that very problem.

The only solution is to have both working hours and scheduling done in
the same time zone.  I could have taken the approach of converting the
start and end times to/from the time zone of the user instead, but I
figured this approach was more consistent with the rest of the design of
OpenERP.

Regards,
-- 
Stuart Longland (aka Redhatter, VK4MSL)      .'''.
Gentoo Linux/MIPS Cobalt and Docs Developer  '.'` :
. . . . . . . . . . . . . . . . . . . . . .   .'.'
http://dev.gentoo.org/~redhatter             :.'

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

-- 
You received this bug notification because you are a member of OpenERP
Indian Team, which is subscribed to OpenERP Addons.
https://bugs.launchpad.net/bugs/932584

Title:
  OpenERP 6.1rc1 emits working hours as local

Status in OpenERP Addons (modules):
  Incomplete

Bug description:
  When OpenERP generates resources for import into faces for resource
  levelling, it emits the times as local time, while emitting and
  interpreting UTC times for the task start and end dates.  This leads
  to funny offsets in the resultant data.

  Attached are two patches:

  0002-resource-Convert-working-hours-to-UTC.patch is a rewrite of
  resource.resource.calculate_working_calendar, which is time-zone
  aware.

  In doing this, I discovered that Faces does _not_ like working hours
  that span midnight.  (Our working hours are 0900-1700, and our local
  time zone is UTC+10, leading to working ours of 2300-0700 UTC.)  Thus,
  I have attached a second patch: 0001-faces-Fix-24-hour-and-end-at-
  midnight-timespans.patch which corrects this behaviour.

  The patch to faces has been submitted upstream:
  https://sourceforge.net/tracker/?func=detail&aid=3487769&group_id=155221&atid=794937

  Known issues:
  - It assumes the user's local time zone, not the time zone of the resource
  - It may break slightly where daylight savings time is involved.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-addons/+bug/932584/+subscriptions