parseInt -> "202103122000" -> NumberFormatException

[PierreDole]

Moin,
ich stehe gerade aufm Schlauch.

Ich bekomme folgende Exception geworfen:
Caused by: java.lang.NumberFormatException: For input string: "202103122000"

Verstehe nicht, warum der Compiler hier meckert, ich sehe da nur Zahlen. 🙂

Hier der Code:

public int getGameDateTime()
    {
        String cleanStartTime = this.startTimeEastern.replace(" ET", "");       
        LocalTime startTime = LocalTime.now();
        
        
        try
        {
            startTime = LocalTime.parse(cleanStartTime, DateTimeFormatter.ofPattern("hh:mm a", Locale.US));           
        }
        catch (java.time.format.DateTimeParseException e)
        {
            startTime = LocalTime.parse(cleanStartTime, DateTimeFormatter.ofPattern("h:mm a", Locale.US));
        }

        
        String startDateTime = String.valueOf(this.startDateEastern) + startTime.format(DateTimeFormatter.ofPattern("HHmm"));
        
        
        return Integer.parseInt(startDateTime); // <- NumberFormatException
    }

 

[temi]

Ich würde sagen der Wert ist zu groß für einen Integer: max Integer = 2,147,483,647

 

[Thallius]

Warum willst du aus einem datetime ein integer machen?

 

[PierreDole]

@temi
Oh, verdammt! Ja, das war's. 🙂

@Thallius
Zum einen ist es ein Bestandteil einer URL und zum anderen ist es für mich leichter Daten damit zu vergleichen.
Zum Beispiel:

if(cacheDownloadDateTime < gameDateTime))
            scoreboard = NBA.getScoreboard(gameDate, Cache.FORCE_UPDATE);

 

[LimDul]

LocalDateTime bietet dafür auch Methoden:

LocalDateTime (Java Platform SE 8 )

 

[temi]

Du kannst auch LocalDateTime vergleichen, z. B. mit isAfter() oder isBefore()

Generell ist es schon vorzuziehen, den passenden Datentypen zu verwenden, anstatt einen "unpassenden" Datentypen anders zu interpretieren.

 

[Thallius]

Oder du nimmst einfach compare() aber das Thema hatten wir schon...

 

[mrBrown]

Warum willst du aus einem datetime ein integer machen?

Warst du nicht der, der immer String für Datumsangaben nutzt? 😉

 

[PierreDole]

Da ich gameDate als int bekomme, musste ich entweder das eine ins andere umwandeln oder umgekehrt. Habs jetzt als LocalDateTime. War ein kleines Gewurstel, da ich das Datum und die Zeit separat bekomme und LocalDateTime nur Datum und Zeit zugleich akzeptiert. Naja, jetzt läufts. 🙂

 

[Thallius]

Warst du nicht der, der immer String für Datumsangaben nutzt? 😉

Wo ist jetzt der Widerspruch?

 

[mrBrown]

Da ich gameDate als int bekomme

Aber doch sicherlich nicht in der Form 202103122000, sondern als Epoch-Days o.ä? '202103122000' ist ein sehr dummes Format für'n Datum, weil das in der Form eben keine Zahl ist.

Wo ist jetzt der Widerspruch?

String ist im Vergleich zu einer (sinnvollen) Zahl einfach das deutlich dümmere Format.

 

[Thallius]

Aber doch sicherlich nicht in der Form 202103122000, sondern als Epoch-Days o.ä? '202103122000' ist ein sehr dummes Format für'n Datum, weil das in der Form eben keine Zahl ist.




String ist im Vergleich zu einer (sinnvollen) Zahl einfach das deutlich dümmere Format.

2021-03-13 12:59:00

ist für mich deutlich sinnvoller als ein timestamp

 

[mrBrown]

2021-03-13 12:59:00

ist für mich deutlich sinnvoller als ein timestamp

Das ist ein Timestamp, nur halt formatiert – was bei nahezu allem nur Nachteile mit sich bringt. Der einzige Vorteil ist ein minimaler Performance-Vorteil, wenn man das einfach nur blind durchschleift, den man sich damit erkauft, dass man nichts anderes sinnvolles machen kann, nicht mal Validierung ob es überhaupt ein Datum/Zeitpunkt ist.

 

[PierreDole]

Aber doch sicherlich nicht in der Form 202103122000, sondern als Epoch-Days o.ä? '202103122000' ist ein sehr dummes Format für'n Datum, weil das in der Form eben keine Zahl ist.

Ich krieg hier sämtliche Formate, die es wohl auf der Welt gibt. 😀

startDateEastern: 20210312
startTimeEastern: "8:00 PM ET"

Habe ich mir nicht ausgedacht. 🙂 Kommt aber noch schlimmer. Um es noch inkonsequenter zu machen, dachte sich die NBA, homeStartDate und visitorStartDate machen wir nicht in der Uhr-Uhrzeit, sondern in der Tagesuhrzeit und ohne Zeitzone:
homeStartTime: "2000".

Und der Veröffentlichungs-Timestamp der Json-Datei ist nochmal anders:
pubDateTime: "2021-03-13 11:50:54.782 EST".

Und weils so viel Spaß macht, noch ein anderes Format:
startTimeUTC: "2021-03-13T01:00:00.000Z"

Naja, man muss nehmen, was man bekommt. 🙂

 

[mihe7]

Der einzige Vorteil ist ein minimaler Performance-Vorteil, wenn man das einfach nur blind durchschleift, den man sich damit erkauft,

dass Vergleiche ggf. wesentlich langsamer werden, weil bei Gleichheit 19 Zeichen verglichen werden müssen. Das mag im Programm nicht die große Rolle spielen, in der DB kann das richtig eklig werden.