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

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)"
to
"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?

-----BEGIN PGP SIGNED MESSAGE-----
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktG88UACgkQzgTEN7l1PDyxKQCgrhHHdfFdD4kgYtki8vkQO9AY
npYAoMuEtsV4LDeA0qBktJUrGL8ZxhFq
=uKSM
-----END PGP SIGNATURE-----

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?

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.

up.

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)

+1

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

Hello,

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.

Thanks

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

Thanks

hello,

Sorry for the noise,

I would reopen the bug , a better solution is on it's way here :https://code.launchpad.net/~openerp-commiter/openobject-client/client_locale_to_user_defined_locale. 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

Thanks

Hello,

It has been improved @https://code.launchpad.net/~openerp-commiter/openobject-client/client_locale_to_user_defined_locale
and will be merged soon to the trunk client.

Thanks,