Message8562

Author santa4nt
Recipients Arfrever, jeff.allen, santa4nt, zyasoft
Date 2014-05-22.04:15:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1400732158.42.0.43796055096.issue2112@psf.upfronthosting.co.za>
In-reply-to
Content
Previous email comment from jeff.allen:

---
Hi Santoso:

Like you I wondered why time.strptime was implemented via an elaborate format translation to use Java date and time parsing. The design of strptime() that uses Java SimpleDateFormat came to us in this changeset:
http://hg.python.org/jython/rev/0091e644d2ec
A peep into Lib at the same revision number is an interesting sight, showing that out of the box Jython would have had no _strptime.py in those days. This may explain it.

*Frank* (and anyone with longer history than we have): We've experienced a series of divergences from CPython here, and Santoso has fixed several, but they keep coming. This patch looks like it might stop that run. Santoso's patch definitively rips out the use of Java parsing in favour of a straightforward call to _strptime._strptime_time(), which is exactly what CPython does. I'll evaluate it (unless you want to) but ...
1. Do you know why the current design is like this?
2. Do you see any secondary consequences to this re-alignment?

If it passes the existing regression tests (which I expect Santoso already did), the other thing it occurs to me to check is localisation. I believe the SimpleDateFormat will be adapting to locale as Java knows it, whereas our localisation leaves a bit to be desired, and doesn't work at all on my rebuilt Windows box. (I'm trying to remember how bad it was before.)

Jeff
History
Date User Action Args
2014-05-22 04:15:58santa4ntsetmessageid: <1400732158.42.0.43796055096.issue2112@psf.upfronthosting.co.za>
2014-05-22 04:15:58santa4ntsetrecipients: + santa4nt, zyasoft, jeff.allen, Arfrever
2014-05-22 04:15:58santa4ntlinkissue2112 messages
2014-05-22 04:15:57santa4ntcreate