NTFTPEntryParser wrong parsing of timestamp 12:24 PM

• Key: NET-51
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Unassigned
• Reporter: Dieter Müller
• Affects Version/s: 1.1

Environment

Operating System: other
Platform: Other

Description

e.g. raw Data: "02-19-04 12:24PM 10728307 FAUSLSILVS.00001"
will result in date: Fri Feb 20 00:24:00 CET 2004
but should be: Thu Feb 19 12:24:00 CET 2004.

Yours,
Dieter Müller

Comments

[Brian Cox]

As far as I can tell, the acceptable range of values for the HOUR field of the
java.util.Calendar instance returned by Calendar.getInstance() is 0 to 11. The
parseFTPEntry method of NTFTPEntryParser feeds the parsed hour component of the
FTP entry's timestamp as-is to the Calendar's HOUR field, which causes the
resulting Calendar value to "skip ahead" 12 hours from the intended value.
Note that, for example, raw data:

"02-19-04 12:24AM 10728307 FAUSLSILVS.00001"

results in Thu Feb 19 12:24:00 2004 rather than Thu Feb 19 00:24:00 2004.

[Brian Cox]

Created an attachment (id=10726)
Filter the parsed hour component to the range 0 .. 11; Add test cases for hour component of 12AM and 12PM

[Steve Cohen]

Created an attachment (id=10738)
Jython script illustrating bug in java.Calendar

[Steve Cohen]

I think you're right; I think this is a bug in java, or at least an undocumented feature since the
0-11 requirement for Calendar.HOUR is not in the javadocs. I just attached a jython script
demonstrating this. (Jython is great for testing java classes this way). The script creates a
Calendar, clears it, then sets its fields one by one. After each set the internals of the Calendar
are printed out. All looks well until getTime() is called, after which the internals are messed up.

I will shortly commit a fix to this problem. The fix will replace the use of Calendar.HOUR with
Calendar.HOUR_OF_DAY which is much more reliable. But I have to do all the work myself,
which sort of defeats the whole purpose of Calendar.

I wonder how long this has been around.

[Steve Cohen]

changed to figure 12:00 am and pm manually, and use Calendar.HOUR_OF_DAY instead of
Calendar.HOUR, due to what appears to be a bug in java.Calendar.

[Steve Cohen]

also note that test updated to check for this. Previously this problem wasn't tested.