On 5/23/05, Andreas Jung <lists@andreas-jung.com> wrote:

I am pretty sure you can build a workaround easily. In my point of view the reason for the change (support for dates outside the usual 1970..2038 scope) is more important.

Well, I don't think we personally use any non-ascii characters, so we can work around it, but it does break backwards compatibility. We get an error when we use localize time and date strings, something I expect is pretty common, i.e., you translate a string "medium_date_format" with whatever translation tool you have, and then pass that as a date format. The translation tools will typically return unicode, and bam! it stops working. So, if we can't properly support unicode, I'd actually prefer that we cast the format string to string, perhaps with a deprecated warning if we pass unicode? -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/