| Thread Previous • Date Previous • Date Next • Thread Next |
On 02/14/2013 04:54 PM, Arturo Galvan Rdz. wrote:
Since the server uses UTC, whenever an account_move gets created
after 5 p.m. its date is set to the next day. That wouldn't be a problem
if the date field of the account.move object were of the type datetime.
In that case we would add (or subtract) the appropriate offset and
obtain the correct date. The way things are, however, we have no way of
knowing if a movement took place on the date stored or on the day before
(with implications for taxes as well as monthly reports, etc.)
That sounds like a bug you could report on https://bugs.launchpad.net/openobject-addons
Have you double-checked that the timezone is properly configured in your user timezone? (even if the datetime values look correct most of the time)
I understand the need to represent something as a date (with no hour)
but we cannot, at present, accurately represent the date of an
account.move because the hour is not included in the date.
Shouldn't all the columns of type date be of the type datetime ??
Actually no, there are good reasons to use a date rather than a datetime, and one of these is that date field do not vary depending on the user who is viewing them. This is a requirement for legal dates such as invoice dates (or journal entries dates).
This does not mean that the date should be incorrect, it must be correctly set just like the invoice dates, depending on who created them. So that really looks like a bug if the user preferences are correct.
Technically the link with the user's timezone may be lost when the journal entry is created due to workflow propagation, but we should still be using the user's timezone when it is properly set. You can mention this on the bug report.
Cheers,
| Thread Previous • Date Previous • Date Next • Thread Next |
