OpenERP 6.1rc1 emits working hours as local

A heads-up: I've created a branch on Launchpad with my workplace's contributions for OpenERP. These two patches are included in this branch.

https://code.launchpad.net/~vrt-openerp/openobject-addons/vrt-openerp

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.

Thanks and waiting for your reply!

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.

Hi Stuart,

Your analysis looks sound and indeed we have to perform the task scheduling on a consistent set of input data: either we convert all input to UTC before scheduling, or we convert everything to a certain local time and then convert the output back to UTC before persisting into the database.

In any case it seems that have a working time that spans midnight is a possible situation, e.g. teams working in 3x8 shift pattern, so fixing Faces to support it properly is great!

Thanks for providing an in-depth analysis, a corresponding set of patches, and also for the upstream submission!

PS: the patches and related merge proposal still have to be reviewed, but currently the MP seems to contain unrelated changes, see my comment on it.