The calendar widget will reject value entry when the locale date format is not 'Standard'

Bug #503624 reported by digitalsatori(Shine IT) on 2010-01-05
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Status tracked in Trunk
Fix Released
OpenERP sa GTK client R&D

Bug Description

The problem stems from the modification of code on rev. 990.1.6

Slicing the date string to fix the length of the date doesn't sound right here, because the separator in date format may not be one byte in length for many locales. For instance, the separator could be of several characters or one character extends several bytes in string. In my case, the Chinese date-time format is like: _年_月_日 _时_分_秒, every Chinese character in the format will extend 3 or more bytes in byte string.

Also, the same assumption of the 'Standard' date time format in whole code base causes many other problems, for example print the report with locale date format. I will report again when I encounter specific problem.

Tony Gu

Related branches

Changed in openobject-client:
assignee: nobody → Olivier Dony (OpenERP) (odo)
Changed in openobject-client:
assignee: Olivier Dony (OpenERP) (odo) → Jay (Open ERP) (jvo-openerp)

This one does not seem to be a regression due to my bugfix for bug 389544, but rather an old regression due to rev 990.1.6>996, and introduced by the "fix" for bug 434068.

@Tiny: could you provide some steps to reproduce this on a "Western-configured" system, such as where you modified the date-time format etc. Could you also elaborate on the 'Standard' date time format issue? For example it is specifically the case in reports that date-times are formatted using the date format specified on the language object (e.g. usually the partner's one).

@Jay: as you originally checked in rev. 990.1.6 for bug 434068, could you review this one? Thanks!

Err, s/@Tiny/@Tony/

Let me explain.

Before 990.1.6, there is no mentioned problem.

on rev. 990.1.6, what Jay did is basicaly change "date1 = DT.strptime(str, self.format)"
"date1 = DT.strptime(str[:10], self.format)" for date format and
"date1 = DT.strptime(str[:19], self.format)" for date-time format.

The above code change will have no effect to the western date format like 2010-01-01 or 2010/01/01. However, it will distort the date string totally for many locales, especially in Eastern Asia. For example, as the value of self.format comes from the operating system locale setting, in Chinese system, the value of self.format is %Y年%m月%d日, and len('年‘)=3, and thus DT.striptime will always throw exception, and the exception handling code simply return False to cause the said problem.

IMHO, the slicing of date string is not necessary, instead, we should have handled irregular date string in exception block, shouldn't we?

Hash: SHA1

Importance: Medium

On 07/01/10 11:04, digitalsatori wrote:
> IMHO, the slicing of date string is not necessary, instead, we should
> have handled irregular date string in exception block, shouldn't we?

Alright, I agree that the brutal slicing of the string is not a correct
way to do it, and we should probably handle this in an exception block.

However, how do we handle unparsable strings? Original bug report seems
to imply that this situation is managed correctly in web and koo
clients, but I can't seem to find the steps to reproduce.
So what was the original reporter trying to do?

Jay, do you know? Or should we ask Ferdinand?
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


Hrm, sorry my mail client messed up that last message.

Basically Tony, you're right, but how do we handle unparsable strings?
What was Ferdinand trying to achieve in bug 434068?

Jay, do you know?

Changed in openobject-client:
importance: Undecided → Medium
William Wan (gogo88er) on 2010-01-10
Changed in openobject-client:
status: New → Confirmed
Changed in openobject-client:
milestone: none → 5.0.8
Changed in openobject-client:
assignee: Jay (Open ERP) (jvo-openerp) → Olivier Dony (OpenERP) (odo)
Changed in openobject-client:
milestone: 5.0.8 → 5.0.9
Changed in openobject-client:
milestone: 5.0.9 → 5.0.10
Changed in openobject-client:
milestone: 5.0.10 → 5.0.11
Changed in openobject-client:
milestone: 5.0.11 → 5.0.12
Dukai Gábor (gdukai) wrote :

I confirm this as a regression with the date format '04.08.2010.' (because it's len > 10).
You can try it on linux with setting
export LC_ALL=sr_RS

Removing the string truncation solves the problem.

Samantha (samantha-z-mathews) wrote :


Changed in openobject-client:
milestone: 5.0.12 → 5.0.13

We can use the dateutil library and the parse method

In [10]: dateutil.parser.parse("04.08.2010.")
Out[10]: datetime.datetime(2010, 4, 8, 0, 0)

Dukai Gábor (gdukai) wrote :


Incredible:) This is the first solution to work reliably:)

IMHO, it's not feasible to use dateutil library and parse method for international date format handling.
The example shown by Stephane utilize the default parserinfo instance, which is defined only for English date/time format.
The below statement will fail with 'unknown string format':

dateutil.parser.parse("2010年8月19日") #Chinese date format
dateutil.parser.parse("01. Januar 2010") #German date format

To allow it parse date format in different language, we will need to provide customized parserinfo for different languages like:
dateutil.parser.parse("2010年8月19日", parserinfo=ChineseParserInfo())
dateutil.parser.parse("01. Januar 2010", parserinfo=GermanParserInfo())

and this will definitely bloat the code

Changed in openobject-client:
assignee: Olivier Dony (OpenERP) (odo) → OpenERP sa GTK client R&D (openerp-dev-gtk)
Naresh(OpenERP) (nch-openerp) wrote :


I would like you all to test your scenarios along with the scenarios stated in LP bug #607470 and #434068 with the latest gtk client as we have improved the date/datetime code. I tested the fix with the windows XP too and seems to work fine now.

If you find any sort of disturbance please post it here so that we can clearly sort the issue.


Naresh(OpenERP) (nch-openerp) wrote :

sorry I forgot to mention the revision info 1738 <email address hidden> on trunk GTK client.


Naresh(OpenERP) (nch-openerp) wrote :


Sorry for the noise,

I would reopen the bug , a better solution is on it's way here : and also the fix for this has caused a regression. which will completely allow user to even change his default locale settings.which should also remove the slicing isuue


Naresh(OpenERP) (nch-openerp) wrote :


It has been improved @
and will be merged soon to the trunk client.


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

Duplicates of this bug

Other bug subscribers