Issue2112

time.strptime() has different default year in Jython and CPython.

$ python2.7 -c 'import time; print(time.strptime("1", "%d"))'
time.struct_time(tm_year=1900, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=0, tm_yday=1, tm_isdst=-1)
$ jython2.7 -c 'import time; print(time.strptime("1", "%d"))'
time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=3, tm_yday=1, tm_isdst=-1)

This is because the underlying date formatter, Java's SimpleDateFormat, uses a calendar that starts from 1970, absent a year given to the parser.

Actually, comparing to cpython implementation, the native code of _time module just simply calls back to a python function in _strptime.py, which jython also packages.

I don't know why the code exists right now to try to use Java's SimpleDateFormat (and falls back to _strptime.py when odd format spec is encountered) instead of just falling back immediately to _strptime.py regardless.

Attaching a proposed patch that comments out the seemingly extraneous Java code (unless I'm missing the original rationale for that code to begin with?). If accepted, might want to clean it up first and delete some code instead of simply commenting out.

Should be in beta 4

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

No-one has objected to the radical surgery, so this is now in the trunk as http://hg.python.org/jython/rev/1f517f1e5a08 . Thanks to Santoso, for solving this one.

The java version was significantly faster, I found that parsing dates out of a large csv file took 5x longer when moving from 2.5 to 2.7.
I'm not saying it's worth trying to maintain it, but users might consider replacing heavy use of strptime with a java method.