Comment 6 for bug 925361

On 02/02/2012 01:50 PM, Gustavo Adrian Marino wrote:
> I fully agree with the concept that dates are timezone agnostic, and thus
> they should be treated as a special case.
> In the example given it is clear the current initialization code is not
> storing HH:MM:SS in the database field. Is not possible to use that fact as
> an indicator we are taking about a timezone agnostic date, a treated
> accordingly on GTK and WEB UI?

Sure, distinguishing the pure date fields from the regular datetime
fields is easy: they are different field types, i.e. declared as
fields.date(...) instead of fields.datetime(), and the client is aware
of that when displaying them.
So we can easily do the right thing for each type - the question is
more: What is the right thing to do? ;-)

> The problem is affecting every place in the system where you are recording
> a date. Thus, and as an example here in Argentina, depending on the time of
> the day, you set a date and magically is converted to the previous day!

Hmm, this should only happen for dates that have been provided by the
system, such as default PO date, etc. It should never happen for dates
that a user would manually enter in a form, as long as the proper
timezone is configured in the user preferences and matches the user's
computer timezone.
Can you confirm this is what you experience?

> Let me say that this problem is a showstopper for any implementation. It
> should be treated as a critical problem, that should be solved before
> publishing the RC as an official version
>
> Please, consider a reevaluation of the priority

We consider this a blocking issue for releasing 6.1 indeed. The new
release will not be published until all Medium (and higher) bugs have
been solved. But this issue only affects the system-provided default
values, and users can manually correct those before saving the new
records, so it is not exactly a form of data corruption. I would say it
is a severe form of misleading and error-prone default values.
I see no issue raising the priority to High if you insist, but at this
point it will not change the way we handle the bug at all...

Thanks everyone for the quick feedback!