> I downloaded it and with a couple mods I was able to use it as a
> substitute for strftime() in timemodule.c. It compiles cleanly and seems
> to pass all tests.
I misspoke. test_strptime fails with timezone issues. That's probably just
my misunderstanding of how Python deals with timezones.
Guido> Someone else will have to do a thorough code review. Last time we
Guido> got something off the web it turned out to be awful (the float
Guido> formatting code -- I'm still reeling from that one).
This isn't some oddball weekend project from an out-of-work programmer.
It's deriv
Someone else will have to do a thorough code review. Last time we got
something off the web it turned out to be awful (the float formatting
code -- I'm still reeling from that one).
On Thu, Apr 3, 2008 at 8:48 PM, <[EMAIL PROTECTED]> wrote:
>
> Guido> Thinking about it more, given the slim ch
On Apr 2, 2008, at 11:52 PM, Guido van Rossum wrote:
> I'd like to see this fixed if possible, but I'm not sure how -- the C
> level 'struct tm' has (year - 1900) in the tm_year member, and I'm not
> sure that implementations are required to do anything with negative
> values there. We'd have to re
Guido> Thinking about it more, given the slim chances that we'll
Guido> reimplement strftime, I think it's okay to fix this for xmlrpc
Guido> specifically.
Is there some reason we can't incorporate a suitable open source
implementation of strftime into the Python core? Here's one exa
On Thu, Apr 3, 2008 at 12:34 AM, Ralf Schmitt <[EMAIL PROTECTED]> wrote:
> Have you considered using the pure python datetime implementation from the
> pypy project for py3k?
I wouldn't dream of it. datetime is considered performance critical by many.
> It's even based on your own code :)
Which
On Thu, Apr 3, 2008 at 12:29 AM, Ralf Schmitt <[EMAIL PROTECTED]> wrote:
> yes, you're right. but I didn't feel like writing a strftime implementation
> (which has probably even less chance of being committed). This patch is
> rather tiny, it's easy to understand and it works now.
Thinking about i
On Thu, Apr 3, 2008 at 5:52 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> I'd like to see this fixed if possible, but I'm not sure how -- the C
> level 'struct tm' has (year - 1900) in the tm_year member, and I'm not
> sure that implementations are required to do anything with negative
> val
On Thu, Apr 3, 2008 at 5:36 AM, <[EMAIL PROTECTED]> wrote:
>
> It's actually not xmlrpclib which has the limitation, but
> datetime.strftime(). That's a known limitation. Here's the comment in
> the
> datetime code:
> [snip]
> Personally, I don't think patching xmlrpclib is the right place to "f
On Wed, Apr 2, 2008 at 8:36 PM, <[EMAIL PROTECTED]> wrote:
> Ralf> anyone care to take a look at:
> Ralf> http://bugs.python.org/issue2014
> Ralf> It's about xmlrpclib not being able to send datetime objects with
> Ralf> dates before 1900.
>
> It's actually not xmlrpclib which has
Ralf> anyone care to take a look at:
Ralf> http://bugs.python.org/issue2014
Ralf> It's about xmlrpclib not being able to send datetime objects with
Ralf> dates before 1900.
It's actually not xmlrpclib which has the limitation, but
datetime.strftime(). That's a known limitation. H
On Wed, Apr 2, 2008 at 11:42 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis schrieb:
> > Can you please explain why this is an important problem?
> > Dates before 1900 have all passed long ago, so they shouldn't
> > occur that often in real applications.
>
In the application wh
Martin v. Löwis schrieb:
> Can you please explain why this is an important problem?
> Dates before 1900 have all passed long ago, so they shouldn't
> occur that often in real applications.
Does xmlrpc support dates for 1900? For historic dates the Julian Day
Number family (MJD or JDN) or Rata Die
> anyone care to take a look at:
> http://bugs.python.org/issue2014
> It's about xmlrpclib not being able to send datetime objects with dates
> before 1900.
> I would like to see this go in and would also like to work on
> http://bugs.python.org/issue1745722
> (xmlrpc wsgi support).
> But this only
14 matches
Mail list logo
