| 2012-04-30 22:05:47 |
Don Kirkby |
bug |
|
|
added bug |
| 2012-04-30 22:06:50 |
Don Kirkby |
description |
This may be similar to the hr_timesheet_sheet bug 943091, and is certainly related to the change in 6.1 to use UTC on all datetime fields in the server, as described in bug 925361. It sounds like the context_today() method helps when calculating date fields based on the current date, but how can we calculate a datetime based on a pure date?
The example scenario I have run into is confirming a sales order.
1. My user timezone is -7:00 PDT.
2. I create a sales order with date 2012-05-01.
3. I confirm the sales order, and look at the picking list.
Expected behaviour: the picking list should either have order date 2012-05-01 00:00:00. Also acceptable would be to ignore the sales order's order date, and use the current datetime for the picking list's order date as it did in version 5.0
Actual behaviour: the picking list has order date 2012-04-30 17:00:00. This is 2012-05-01 midnight UCT adjusted for the user's time zone.
I am running 6.1.0 on Ubuntu 10.04. |
This may be similar to the hr_timesheet_sheet bug 943091, and is certainly related to the change in 6.1 to use UTC on all datetime fields in the server, as described in bug 925361. It sounds like the context_today() method helps when calculating date fields based on the current date, but how can we calculate a datetime based on a pure date?
The example scenario I have run into is confirming a sales order.
1. My user timezone is -7:00 PDT.
2. I create a sales order with date 2012-05-01.
3. I confirm the sales order, and look at the picking list.
Expected behaviour: the picking list should have order date 2012-05-01 00:00:00. Also acceptable would be to ignore the sales order's order date, and use the current datetime for the picking list's order date as it did in version 5.0
Actual behaviour: the picking list has order date 2012-04-30 17:00:00. This is 2012-05-01 midnight UCT adjusted for the user's time zone.
I am running 6.1.0 on Ubuntu 10.04. |
|
| 2012-04-30 22:13:16 |
Don Kirkby |
description |
This may be similar to the hr_timesheet_sheet bug 943091, and is certainly related to the change in 6.1 to use UTC on all datetime fields in the server, as described in bug 925361. It sounds like the context_today() method helps when calculating date fields based on the current date, but how can we calculate a datetime based on a pure date?
The example scenario I have run into is confirming a sales order.
1. My user timezone is -7:00 PDT.
2. I create a sales order with date 2012-05-01.
3. I confirm the sales order, and look at the picking list.
Expected behaviour: the picking list should have order date 2012-05-01 00:00:00. Also acceptable would be to ignore the sales order's order date, and use the current datetime for the picking list's order date as it did in version 5.0
Actual behaviour: the picking list has order date 2012-04-30 17:00:00. This is 2012-05-01 midnight UCT adjusted for the user's time zone.
I am running 6.1.0 on Ubuntu 10.04. |
This may be similar to the hr_timesheet_sheet bug 943091, and is certainly related to the change in 6.1 to use UTC on all datetime fields in the server, as described in bug 925361. It sounds like the context_today() method helps when calculating date fields based on the current date, but how can we calculate a datetime based on a pure date?
The example scenario I have run into is confirming a sales order.
1. My user timezone is -7:00 PDT.
2. I create a sales order with date 2012-05-01.
3. I confirm the sales order, and look at the picking list.
Expected behaviour: the picking list should either have order date 2012-05-01 00:00:00. Also acceptable would be to ignore the sales order's order date, and use the current datetime for the picking list's order date as it did in version 5.0
Actual behaviour: the picking list has order date 2012-04-30 17:00:00. This is 2012-05-01 midnight UCT adjusted for the user's time zone.
The calculation is happening in the sale_order._get_date_planned() method here:
http://bazaar.launchpad.net/~openerp/openobject-addons/trunk/view/6619/sale/sale.py#L791
I am running 6.1.0 on Ubuntu 10.04. |
|
| 2012-04-30 22:21:51 |
Don Kirkby |
description |
This may be similar to the hr_timesheet_sheet bug 943091, and is certainly related to the change in 6.1 to use UTC on all datetime fields in the server, as described in bug 925361. It sounds like the context_today() method helps when calculating date fields based on the current date, but how can we calculate a datetime based on a pure date?
The example scenario I have run into is confirming a sales order.
1. My user timezone is -7:00 PDT.
2. I create a sales order with date 2012-05-01.
3. I confirm the sales order, and look at the picking list.
Expected behaviour: the picking list should either have order date 2012-05-01 00:00:00. Also acceptable would be to ignore the sales order's order date, and use the current datetime for the picking list's order date as it did in version 5.0
Actual behaviour: the picking list has order date 2012-04-30 17:00:00. This is 2012-05-01 midnight UCT adjusted for the user's time zone.
The calculation is happening in the sale_order._get_date_planned() method here:
http://bazaar.launchpad.net/~openerp/openobject-addons/trunk/view/6619/sale/sale.py#L791
I am running 6.1.0 on Ubuntu 10.04. |
This may be similar to the hr_timesheet_sheet bug 943091, and is certainly related to the change in 6.1 to use UTC on all datetime fields in the server, as described in bug 925361. It sounds like the context_today() method helps when calculating date fields based on the current date, but how can we calculate a datetime based on a pure date?
The example scenario I have run into is confirming a sales order.
1. My user timezone is -7:00 PDT.
2. I create a sales order with date 2012-05-01.
3. I confirm the sales order, and look at the picking list.
Expected behaviour: the picking list should either have order date 2012-05-01 00:00:00. Also acceptable would be to ignore the sales order's order date, and use the current datetime for the picking list's order date as it did in version 5.0
Actual behaviour: the picking list has order date 2012-04-30 17:00:00. This is 2012-05-01 midnight UCT adjusted for the user's time zone.
I am running 6.1.0 on Ubuntu 10.04. |
|
| 2012-05-01 17:06:26 |
Don Kirkby |
description |
This may be similar to the hr_timesheet_sheet bug 943091, and is certainly related to the change in 6.1 to use UTC on all datetime fields in the server, as described in bug 925361. It sounds like the context_today() method helps when calculating date fields based on the current date, but how can we calculate a datetime based on a pure date?
The example scenario I have run into is confirming a sales order.
1. My user timezone is -7:00 PDT.
2. I create a sales order with date 2012-05-01.
3. I confirm the sales order, and look at the picking list.
Expected behaviour: the picking list should either have order date 2012-05-01 00:00:00. Also acceptable would be to ignore the sales order's order date, and use the current datetime for the picking list's order date as it did in version 5.0
Actual behaviour: the picking list has order date 2012-04-30 17:00:00. This is 2012-05-01 midnight UCT adjusted for the user's time zone.
I am running 6.1.0 on Ubuntu 10.04. |
This may be similar to the hr_timesheet_sheet bug 943091, and is certainly related to the change in 6.1 to use UTC on all datetime fields in the server, as described in bug 925361. It sounds like the context_today() method helps when calculating date fields based on the current date, but how can we calculate a datetime based on a pure date?
The example scenario I have run into is confirming a sales order.
1. My user timezone is -7:00 PDT.
2. I create a sales order with date 2012-05-01.
3. I confirm the sales order, and look at the picking list.
Expected behaviour: the picking list should either have order date 2012-05-01 00:00:00. Also acceptable would be to ignore the sales order's order date, and use the current datetime for the picking list's order date as it did in version 5.0
Actual behaviour: the picking list has order date 2012-04-30 17:00:00. This is 2012-05-01 midnight UTC adjusted for the user's time zone.
I am running 6.1.0 on Ubuntu 10.04. |
|
| 2012-05-02 13:39:57 |
Ravish(OpenERP) |
attachment added |
|
Watch this video for more info..!! https://bugs.launchpad.net/openobject-addons/+bug/992259/+attachment/3125095/+files/sale_timezone.ogv |
|
| 2012-05-02 13:40:45 |
Ravish(OpenERP) |
openobject-addons: status |
New |
Incomplete |
|
| 2012-05-02 18:38:24 |
Don Kirkby |
description |
This may be similar to the hr_timesheet_sheet bug 943091, and is certainly related to the change in 6.1 to use UTC on all datetime fields in the server, as described in bug 925361. It sounds like the context_today() method helps when calculating date fields based on the current date, but how can we calculate a datetime based on a pure date?
The example scenario I have run into is confirming a sales order.
1. My user timezone is -7:00 PDT.
2. I create a sales order with date 2012-05-01.
3. I confirm the sales order, and look at the picking list.
Expected behaviour: the picking list should either have order date 2012-05-01 00:00:00. Also acceptable would be to ignore the sales order's order date, and use the current datetime for the picking list's order date as it did in version 5.0
Actual behaviour: the picking list has order date 2012-04-30 17:00:00. This is 2012-05-01 midnight UTC adjusted for the user's time zone.
I am running 6.1.0 on Ubuntu 10.04. |
This may be similar to the hr_timesheet_sheet bug 943091, and is certainly related to the change in 6.1 to use UTC on all datetime fields in the server, as described in bug 925361. It sounds like the context_today() method helps when calculating date fields based on the current date, but how can we calculate a datetime based on a pure date?
The example scenario I have run into is confirming a sales order.
1. My OpenERP user timezone is -7:00 PDT. (Set in the OpenERP user preferences.)
2. I create a sales order with date 2012-05-01.
3. I confirm the sales order, and look at the picking list.
Expected behaviour: the picking list should have order date 2012-05-01 00:00:00. Also acceptable would be to ignore the sales order's order date, and use the current datetime for the picking list's order date as it did in version 5.0.
Actual behaviour: the picking list has order date 2012-04-30 17:00:00. This is 2012-05-01 midnight UTC adjusted for the user's time zone.
I am running 6.1.1 on Ubuntu 10.04. |
|
| 2012-05-02 18:38:36 |
Don Kirkby |
openobject-addons: status |
Incomplete |
New |
|
| 2012-05-03 13:19:41 |
Ravish(OpenERP) |
summary |
Calculating datetime from date cause timezone issues in sales order |
[6.1]Calculating datetime from date cause timezone issues in sales order |
|
| 2012-05-03 13:19:51 |
Ravish(OpenERP) |
openobject-addons: status |
New |
Confirmed |
|
| 2012-05-03 13:20:16 |
Ravish(OpenERP) |
openobject-addons: importance |
Undecided |
Low |
|
| 2012-05-03 13:20:28 |
Ravish(OpenERP) |
openobject-addons: assignee |
|
OpenERP Publisher's Warranty Team (openerp-opw) |
|
| 2012-10-26 00:19:40 |
Don Kirkby |
description |
This may be similar to the hr_timesheet_sheet bug 943091, and is certainly related to the change in 6.1 to use UTC on all datetime fields in the server, as described in bug 925361. It sounds like the context_today() method helps when calculating date fields based on the current date, but how can we calculate a datetime based on a pure date?
The example scenario I have run into is confirming a sales order.
1. My OpenERP user timezone is -7:00 PDT. (Set in the OpenERP user preferences.)
2. I create a sales order with date 2012-05-01.
3. I confirm the sales order, and look at the picking list.
Expected behaviour: the picking list should have order date 2012-05-01 00:00:00. Also acceptable would be to ignore the sales order's order date, and use the current datetime for the picking list's order date as it did in version 5.0.
Actual behaviour: the picking list has order date 2012-04-30 17:00:00. This is 2012-05-01 midnight UTC adjusted for the user's time zone.
I am running 6.1.1 on Ubuntu 10.04. |
This may be similar to the hr_timesheet_sheet bug 943091, and is certainly related to the change in 6.1 to use UTC on all datetime fields in the server, as described in bug 925361. It sounds like the context_today() method helps when calculating date fields based on the current date, but how can we calculate a datetime based on a pure date?
The example scenario I have run into is confirming a sales order.
1. My OpenERP user timezone is -7:00 PDT. (Set in the OpenERP user preferences.)
2. I create a sales order with date 2012-05-01.
3. I confirm the sales order, and look at the picking list.
Expected behaviour: the picking list should have order date 2012-05-01 00:00:00. Also acceptable would be to ignore the sales order's order date, and use the current datetime for the picking list's order date as it did in version 5.0.
Actual behaviour: the picking list has order date 2012-04-30 17:00:00. This is 2012-05-01 midnight UTC adjusted for the user's time zone.
A similar problem exists on the procurement table when moving from the wizard's date field to the table's datetime field.
I am running 6.1.1 on Ubuntu 10.04. |
|
| 2012-12-05 05:02:38 |
saurabh kumar pandey |
bug |
|
|
added subscriber saurabh kumar pandey |
| 2014-01-07 06:49:19 |
Twinkle Christian(OpenERP) |
tags |
|
hr |
|
