Return-Path: Delivered-To: apache-bugdb-archive@hyperreal.org Received: (qmail 28412 invoked by uid 6000); 5 Feb 1999 16:50:05 -0000 Received: (qmail 28329 invoked by uid 2001); 5 Feb 1999 16:50:02 -0000 Date: 5 Feb 1999 16:50:02 -0000 Message-ID: <19990205165002.28328.qmail@hyperreal.org> To: jserv-bugdb@apache.org Cc: apache-bugdb@apache.org, From: Jochen Schwarze Subject: Re: mod_jserv/3788: StringIndexOutOfBoundsException thrown in JServConnection.getDateHeader() Reply-To: Jochen Schwarze Sender: apache-bugdb-owner@apache.org Precedence: bulk The following reply was made to PR mod_jserv/3788; it has been noted by GNATS. From: Jochen Schwarze To: apbugs@hyperreal.org Cc: Chris Knight Subject: Re: mod_jserv/3788: StringIndexOutOfBoundsException thrown in JServConnection.getDateHeader() Date: Fri, 5 Feb 1999 17:42:54 +0100 (MET) I also experience this problem on a Sparc Solaris 2.6 with bundled Java 1.1.6 (so no Blackdown Linux Java problem), at line 1223 of JServConnection.java, 1.0b2, so parsing the "EEE, dd MMM yyyy HH:mm:ss zzz" format fails. This is probably a problem in Sun's code. A sample date string is here: Fri, 05 Feb 1999 16:27:34 GMT I've tried to reproduce the problem with a small sample class like this: import java.util.*; import java.text.*; public class TryDate { public static void main(String[] args) { getDateHeader("Fri, 05 Feb 1999 14:11:33 GMT"); } static public long getDateHeader(String val) { SimpleDateFormat sdf; if ( val == null ) { return -1; } sdf = new SimpleDateFormat("EEE, dd MMM yyyy HH:mm:ss zzz"); try { Date date = sdf.parse(val); return date.getTime(); } catch(ParseException formatNotValid) { // try another format } sdf = new SimpleDateFormat("EEEEEE, dd-MMM-yy HH:mm:ss zzz"); try { Date date = sdf.parse(val); return date.getTime(); } catch(ParseException formatNotValid) { // Try another format } sdf = new SimpleDateFormat("EEE MMMM d HH:mm:ss yyyy"); try { Date date = sdf.parse(val); return date.getTime(); } catch(ParseException formatStillNotValid) { throw new IllegalArgumentException(val); } } } But suprisingly, it does _not_ reproduce the problem! Any ideas? Regards, Jochen -- Jochen Schwarze