On 5/24/05, Andreas Jung [EMAIL PROTECTED] wrote:
+if isinstance(unicode, format):
Well, this should be if isinstance(format, unicode): of course.
But besides that, yes it works.
--
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content Management http://www.cps-project.org/
DateTime.DateTime.strftime(fmt) used to use strftime, which accepts a
unicode string as fmt. In 2.8 it uses datetime.datetime.strftime which
does not accept unicode.
This both breaks backwards compatibility, and prevents you from using
non-ascii characters in the format string.
Thoughts,
--On Montag, 23. Mai 2005 19:22 Uhr +0200 Lennart Regebro
[EMAIL PROTECTED] wrote:
DateTime.DateTime.strftime(fmt) used to use strftime, which accepts a
unicode string as fmt. In 2.8 it uses datetime.datetime.strftime which
does not accept unicode.
This both breaks backwards compatibility,
On 5/23/05, Andreas Jung [EMAIL PROTECTED] 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
--On Montag, 23. Mai 2005 20:22 Uhr +0200 Lennart Regebro
[EMAIL PROTECTED] wrote:
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
On 5/23/05, Andreas Jung [EMAIL PROTECTED] wrote:
A deprecation warning could do the job. To be honest I would have never
thought about
such a usecase :-) However we could convert unicode to utf8 and use this as
argument
for strftime() and converting the result back to unicode.
Yeah, that
--On Montag, 23. Mai 2005 20:40 Uhr +0200 Lennart Regebro
[EMAIL PROTECTED] wrote:
On 5/23/05, Andreas Jung [EMAIL PROTECTED] wrote:
A deprecation warning could do the job. To be honest I would have never
thought about
such a usecase :-) However we could convert unicode to utf8 and use
