SimpleDateFormat ?

[thE_29]

Hi!

Also, ich hab grad was gebaut, was mir eine Zeitüberprüfung machen soll! (PlainDocument)


Und bin hier draufgekommen, dass das SimpleDateFormat keine Exception liefert, wenn man die Einerzahl bei Minuten einen Buchstaben!!!!! eingibt!

Bsp.:

    try{
      SimpleDateFormat fmt = new SimpleDateFormat("HH:mm");
      fmt.setLenient(false);
      java.util.Date d = fmt.parse("12:3X");
      System.out.println(fmt.format(d));
    }
    catch(Exception ex)
    {
      ex.printStackTrace();
    }

Ausgabe ist in Java 1.5.0.01_b08 und Java 1.4.2_b06 immer 12:03!


Ich meine was soll dieser verdammte Bullshit??

Ich will wissen ob das ne zulässige Zahl ist und der sagt ja und gibt mir irgendnen Bledsinn aus....


Wie soll ich den jetzt abprüfen ob es sich nur um eine Zahl handelt....

 

[stev.glasow]

Wirklich eigenartig.
Würd's mit nem Regex machen:

DateFormat fmt = new SimpleDateFormat("HH:mm");
String str = "12:33";
if(!str.matches("\\d\\d:\\d\\d")){
   	throw new ParseException("foo", 0);
}
Date d = fmt.parse(str);

System.out.println(fmt.format(d));

 

[Guest]

Ist normal. Jeder der Parser aus der API (NumberFormat/Decimalformat etc.)
liest die Eingabe nur solange, solange er die Eingabe erkennt.

 

[thE_29]

Was??

... Glaube aber ich weiß was du meinst!

Wenn ich sage der InitString ist HH:mm:ss und ich gebe 12:3x ein gehts net!

Gebe ich aber 12:30:7x ein gehts wieder!

Also wird das letzte Zeichen nie uberprüft?? Wasn das fürn Mist?

 

[KSG9|sebastian]

dann musst du halt überprüfen ob die eingabe ene gültige zahl ist...

 

[stev.glasow]

Also wird das letzte Zeichen nie uberprüft? Wasn das fürn Mist?

War das jetzt ne Frage? Wann ja:
doch, wenn du 12:30:26 angibst nimmt er die 6 ja mit rein. Wär doch Schwachsin wenn er grundsätzlich das letzte Zeichen ignoriert.

 

[bygones]

was ist das Problem - java scheint das nicht zu überprüfen.. also einen einzeiler noch hinzugefügt und dann klappts...

 

[Bleiglanz]

hatten wir gerade schonmal mit doubles


die Parser in java.text sind alle gutmütig, dh die lesen nur bis zum ersten nicht passenden Zeichen und ignorieren den Rest

wenn man das nicht will und gleichzeitig mit verschiedenen Locales arbeiten dann muss man das ganze nochmal extra mit regexen oder anderen Mitteln testen

echter schwachpunkt??

Wenn ich sage der InitString ist HH:mm:ss und ich gebe 12:3x ein gehts net!
Gebe ich aber 12:30:7x ein gehts wieder!

passt doch, beim ersten fehlt der zweite :, beim zweiten ist eben 12:30:7 schon eine gültige Eingabe...

 

[thE_29]

Ja, aber

1. wirft er keine Exception

2. ist die Uhrzeit dann 12:30:07 => dh, er bildet sich ein man hat 12:30:07 eingegeben, was ja überhaupt net stimmt, da ich ja 12:30:7X eingegeben habe!!


@dbac: mir gehts ja net um den 1Zeiler, der is schon drinnen, aber es ist halt nervend, das er das LETZTE Zeichen nie uberprüft!!

 

[Bleiglanz]

Ja, aber
1. wirft er keine Exception
2. ist die Uhrzeit dann 12:30:07 => dh, er bildet sich ein man hat 12:30:07 eingegeben, was ja überhaupt net stimmt, da ich ja 12:30:7X eingegeben habe!!

das meinte ich mit "zu gutmütig"

probier mal "12:30:7XQUARKEINGABE"

 

[Jörg]

By default, parsing is lenient: If the input is not in the form used by this object's format method but can still be parsed as a date, then the parse succeeds. Clients may insist on strict adherence to the format by calling setLenient(false).

API: DateFormat#parse(String,ParsePosition)

 

[Jörg]

sollte dir helfen denk ich

 

[thE_29]

Ähm, auch wenn ich jetzt gemein bin, aber schau mal genau

Das rufe ich so und so auf :bae:

 

[Bleiglanz]

wäre schön gewesen, ist aber leider nix

setLenient beeinflusst nur das Überpringen (10:70 ist 11:10), der Parser selbst bleibt trotzdem zu nett

java.text.SimpleDateFormat df = new java.text.SimpleDateFormat("HH:mm");
System.out.println(df.parse("10:1x"));//Thu Jan 01 10:01:00 CET 1970
System.out.println(df.parse("10:70"));//Thu Jan 01 11:10:00 CET 1970
df.setLenient(false);
System.out.println(df.parse("9:9UNDNOCHMIST"));//Thu Jan 01 09:09:00 CET 1970
System.out.println(df.parse("10:70"));//java.text.ParseException: Unparseable date: "10:70

 

[thE_29]

Naja, das setLenient lasst das 70 eben nicht zu!

Deswegen habe ich das ja eingebaut, sodaß man keine nicht Uhrzeitzahlen eingeben kann (wie 7 eben).


Aber das er auf die letzte Stelle nie uberprüft ist und bleibt ärgerlich...