Title: time.strptime() has different default year in Jython and CPython
Type: behaviour Severity: normal
Components: Core Versions: Jython 2.7
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: jeff.allen Nosy List: Arfrever, jeff.allen, santa4nt, tcoker, zyasoft
Priority: normal Keywords: patch

Created on 2014-01-12.22:20:53 by Arfrever, last changed 2016-03-09.14:33:12 by tcoker.

File name Uploaded Description Edit Remove
issue2112.patch santa4nt, 2014-01-14.06:46:44 comment out native implementation of strptime.
issue2112.patch santa4nt, 2014-01-14.21:09:51 A more complete patch.
msg8225 (view) Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) Date: 2014-01-12.22:20:53
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)
msg8230 (view) Author: Santoso Wijaya (santa4nt) Date: 2014-01-14.06:46:44
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, 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 when odd format spec is encountered) instead of just falling back immediately to 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.
msg8547 (view) Author: Jim Baker (zyasoft) Date: 2014-05-22.01:44:42
Should be in beta 4
msg8562 (view) Author: Santoso Wijaya (santa4nt) Date: 2014-05-22.04:15:57
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:
A peep into Lib at the same revision number is an interesting sight, showing that out of the box Jython would have had no 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.)

msg8630 (view) Author: Jeff Allen (jeff.allen) Date: 2014-06-12.07:06:24
No-one has objected to the radical surgery, so this is now in the trunk as . Thanks to Santoso, for solving this one.
msg10804 (view) Author: Tom Coker (tcoker) Date: 2016-03-09.14:33:11
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.
Date User Action Args
2016-03-09 14:33:12tcokersetnosy: + tcoker
messages: + msg10804
2014-06-12 07:06:24jeff.allensetstatus: open -> closed
messages: + msg8630
2014-05-22 04:15:58santa4ntsetmessages: + msg8562
2014-05-22 01:44:42zyasoftsetresolution: accepted
messages: + msg8547
nosy: + zyasoft
2014-01-25 23:09:30jeff.allensetpriority: normal
assignee: jeff.allen
2014-01-14 21:09:51santa4ntsetfiles: + issue2112.patch
2014-01-14 16:38:53santa4ntsetversions: + Jython 2.7
2014-01-14 06:46:45santa4ntsetfiles: + issue2112.patch
keywords: + patch
type: behaviour
messages: + msg8230
components: + Core
2014-01-12 22:20:53Arfrevercreate