date format should be set in server instead of client

Bug #821060 reported by Mihai Satmarean
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Odoo Server (MOVED TO GITHUB)
Confirmed
Wishlist
OpenERP's Framework R&D

Bug Description

We are having a lot of trouble using date in dd.mm.yyyy format (Romanian format), because on some computers the with win xp are set to english us by default. Also when restoring from backup or any change the windows gets back to english us, and a lot of things go wrong.

Also I suspect some bugs around this issue but I cannot prove them. The fact is that we have a lot of confusion going on.

I do not really see the benefit of having the client determining the date format, because I can now connect from a lot of different devices and then you need to be careful to have correct locale set.

I think that also for us system administrators would be much easy to have it in the server.

Can somebody point me where I can change this in the code of the client?

Thanks.

Amit Parik (amit-parik)
affects: openobject-addons → openobject-server
Changed in openobject-server:
assignee: nobody → OpenERP's Framework R&D (openerp-dev-framework)
importance: Undecided → Wishlist
status: New → Confirmed
Revision history for this message
xrg (xrg) wrote : Re: [Bug 821060] [NEW] date format should be set in server instead of client

On Friday 05 August 2011, you wrote:
> You have been subscribed to a public bug:
>
> We are having a lot of trouble using date in dd.mm.yyyy format (Romanian
> format), because on some computers the with win xp are set to english us
> by default. Also when restoring from backup or any change the windows
> gets back to english us, and a lot of things go wrong.

The fact that Windows XP screw the settings is not enough to change the
overall behaviour of OpenERP (which shall remain platform independent).

If you are about to do something, please confine it only for that broken
platform.

For example, you could set a special "server" value as the GTK client's saved
locale setting, meaning that the client should ignore OS-supplied info and
always try the server's context value.

Revision history for this message
Mihai Satmarean (mihai-satmarean) wrote :

I agree that OpenERP should remain platform independent, (my proposal does not affect that)
my proposal was to store the date display setting in the database, so would be displayed in the same format on any device that we connect to the server no matter what locale the device has set.

Perhaps the current behavior is nice for a multinational company, but we are a small company and we find no use for it.

I am not saying to change OpenERP because I want to or our company wants to, the OpenERP project has brought ERP to any company of any size, so it should provide a way to use it as flexible as possible. That is the strenght of OpenERP.

@xrg
I am not an experienced python programmer, If you have an idea how could my request be achieved, please share your idea and I will make it for our company, and post it on the launchpad in our branch, and if somebody else need it will be available there.

Thanks

Revision history for this message
xrg (xrg) wrote : Re: [Bug 821060] Re: date format should be set in server instead of client

On Saturday 06 August 2011, you wrote:
> I agree that OpenERP should remain platform independent, (my proposal does
> not affect that) my proposal was to store the date display setting in the
> database, so would be displayed in the same format on any device that we
> connect to the server no matter what locale the device has set.
>
> Perhaps the current behavior is nice for a multinational company, but we
> are a small company and we find no use for it.
>
> I am not saying to change OpenERP because I want to or our company wants
> to, the OpenERP project has brought ERP to any company of any size, so
> it should provide a way to use it as flexible as possible. That is the
> strenght of OpenERP.
>
>
> @xrg
> I am not an experienced python programmer, If you have an idea how could my
> request be achieved, please share your idea and I will make it for our
> company, and post it on the launchpad in our branch, and if somebody else
> need it will be available there.
>
> Thanks

The setting for date format is already under the 'res.language', so it *is*
stored in the server.
The algorithm of fetching this information, per session, into the GTK client
is what we are discussing about.

BQI> describe res.lang
                                          Model: "res.lang"
    Field | String | Type | Modifiers
-----------------------------------------------------------------------------------------------------
name |Name |char(64) |required selectable
active |Active |boolean |selectable
code |Locale Code |char(16) |required selectable
date_format |Date Format |char(64) |required selectable
decimal_point|Decimal Separator |char(64) |required selectable
direction |Direction |selection|selection=(ltr, rtl) required
selectable
grouping |Separator Format |char(64) |required selectable
iso_code |ISO code |char(16) |selectable
thousands_sep|Thousands Separator|char(64) |selectable
time_format |Time Format |char(64) |required selectable
translatable |Translatable |boolean |selectable

Revision history for this message
Mihai Satmarean (mihai-satmarean) wrote :

I do have it defined in the server, but still on the client side is wrongly interpreted, so is clearly a problem.
The problem of the client not taking the value defined in the server but other twisted value.

Just my impression.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.