[java] Bug in SimpleDateFormat?

[ajvdvegt]

Bij het parsen van een string die een tijd-zone bevat, lijkt die tijdzone door de SimpleDateFormat genegeerd te worden. Iemand die dit wel eens is tegen gekomen en weet wat ik er aan kan doen?

Zie onderstaande code. Ik maak twee SimpelDateFormatters aan; eentje die wel een tijdzone 'snapt' en eentje die dat niet doet. Ik stop in beiden dezelfde tijd, en forceer de ene naar CET. Beiden zouden m.i. hetzelfde resultaat moeten geven, maar dat is niet zo.

Java:

public static void main(String[] args) {
  Date d;

  String timeCetZone = "2005-10-03 02:00 CET";        
  SimpleDateFormat reportDateZone = new SimpleDateFormat("yyyy-MM-dd HH:mm z");
  d = reportDateZone.parse(timeCetZone);
  System.out.println(timeCetZone + " ==> " + d.getTime());

  String timeCet = "2005-10-03 02:00";
  SimpleDateFormat reportDate = new SimpleDateFormat("yyyy-MM-dd HH:mm");
  TimeZone timeZone = TimeZone.getTimeZone("CET");
  reportDate.setTimeZone(timeZone);
  d = reportDate.parse(timeCet);
  System.out.println(timeCet + " ==> " + d.getTime());
}

Het resultaat is:(spaties toegevoegd voor de opmaak)

code:

2005-10-03 02:00 CET ==> 1128301200000
2005-10-03 02:00     ==> 1128297600000

NB de eerste is dus niet goed, dat is namelijk als je het weer terug rekent 2005-10-03 03:00 CET. Het werkt trouwens wel als ik CEST invoer als tijdzone, maar dat bestaat niet volgens TimeZone.getAvailableIDs().

[Confusion]

Ik kwam deze aardige link tegen. Niet helemaal relevant, maar misschien wel een aanrader om toch niet de drieletterige codes te gebruiken...

[ajvdvegt]

Bedank voor de link! Dat die drie letterige codes depricated zijn staat wel in de JavaDocs, maar Dat deel heb ik niet voor het zeggen. De SimpleDateFormatter kan trouwens niet met de langer overweg, hij valt over 'Europe/Amsterdam'.

[momania]

ajvdvegt schreef op dinsdag 04 oktober 2005 @ 17:41:
Bedank voor de link! Dat die drie letterige codes depricated zijn staat wel in de JavaDocs, maar Dat deel heb ik niet voor het zeggen. De SimpleDateFormatter kan trouwens niet met de langer overweg, hij valt over 'Europe/Amsterdam'.

Ook niet als je ipv 'z' -> 'zz' of 'zzz' opgeeft ?

[Robtimus]

Java's tijd berekeningen zijn wel vaker wat off.

Pas geleden opgemerkt: ik heb een Calendar (via Calendar.getInstance()). Ik zet het jaar (maakt niet uit welk), zet de maand op 1 (februari). Vervolgens roep ik getActualMaximum() aan voor de maand, wat het werkelijke aantal dagen in de maand moet teruggeven. Antwoord: 31. Pas als ik het jaar en de maand nog een keer zet, zelfs al is het de exact zelfde waarde (misschien is 1 van beide genoeg) dan krijg ik netjes 28 of 29. Ik gebruik Java 1.4.2_06.

[Confusion]

Als je de tijdzone vervangt door GMT komt er twee keer hetzelfde uit. Bij alle andere tijdzones zit er telkens een uur verschil tussen. Misschien dat met setTimeZone de DST instelling niet geset wordt en hij daar een default voor gebruikt, terwijl de constructor met de tijdzone informatie deze wel zet? Het lijkt me in ieder geval dat een uur verschil aan de DST ligt.

[ Voor 4% gewijzigd door Confusion op 04-10-2005 20:41 ]

[CubicQ]

Geen oplossing oid, maar ik dacht, laat ik het eens onder een IBM JVM (cn131-20020710) proberen:

2005-10-03 02:00 CET ==> 1128301200000
2005-10-03 02:00 ==> 1128304800000

De eerste is hetzelfde als bij jouw JVM, de tweede is anders.

[ajvdvegt]

@Confusion: Dat het iets met DST (day light savings - zomer/wintertijd voor wie het niet kent) leek me ook al. Als ik deze site lees kent de CET zone inderdaad geen DST, maar volgens mij is dat onzin. En Java geeft mij elders gelijk. De simpele opdracht

code:

System.out.println(TimeZone.getTimeZone("CET"));

geeft toch duidelijk aan dat er wel DST zit.

Ook op de site die ik noemde wordt gezegd dat de CET-zone 's zomers CEST is, maar die tijdzone komt helemaal niet voor in het lijstje van TimeZone.getAvailableIDs() (en twee tijdzones inhet jaar is ook irritant....).

Ik heb het vooralsnog opgelost door de SimpleDateFormat te extenden, en daar dan de constructor, applyPattern() en parse() zelf in te vullen. Deze oplossing is welliswaar niet generiek (ik ga niet zelf de pattern-string lopen parsen ) maar voldoet voor mijn situatie (de tijdzone mag alleen voorkomen als laatste element van de pattern-string, voorafgegaan door een spatie).

Generiekere oplossingen zijn altijd welkom natuurlijk

Ik gebruik Sun Java 1.4.2_08 trouwens....

[ Voor 4% gewijzigd door ajvdvegt op 04-10-2005 21:23 ]

[ajvdvegt]

momania schreef op dinsdag 04 oktober 2005 @ 17:45:
[...]
Ook niet als je ipv 'z' -> 'zz' of 'zzz' opgeeft ?

Nee, geeft ook een parse exception helaas.

[ajvdvegt]

CubicQ schreef op dinsdag 04 oktober 2005 @ 21:16:
Geen oplossing oid, maar ik dacht, laat ik het eens onder een IBM JVM (cn131-20020710) proberen:

2005-10-03 02:00 CET ==> 1128301200000
2005-10-03 02:00 ==> 1128304800000

De eerste is hetzelfde als bij jouw JVM, de tweede is anders.

Tnx, ook interessant. Bij jou is er ook een uur tijdsverschil, maar de andere kant op. Alsof bij jou in het tweede geval CEST is gebruikt. Wat is jouw default timezone (TimeZone.getDefault())? Mijne is Europe/Amsterdam.

Hee, ik zie nu dat Eclipse me de source van SimpleDateFormat laat zien... JBuilder deed dat vanmiddag niet!

[ajvdvegt]

Na de source te hebben bekeken weet ik dit:

- De DateFormatSymbols() class wordt gebruikt om de namen van tijdzones in te vullen.
- Er wordt daarin alleen gezocht op de velden 1 tot en met 4 (winter/zomertijd, voluit en afgekort) --> daarom werkt Europe/Amsterdam niet.
- De variabele useSameName geeft aan of zomer en wintertijd gelijk zijn in dit laatste stukje code:

Java:

    if (tz != null) { // Matched any ?
        if (!tz.equals(currentTimeZone)) {
            setTimeZone(tz);
        }
        // If the time zone matched uses the same name
        // (abbreviation) for both standard and daylight time,
        // let the time zone in the Calendar decide which one.
        if (!useSameName) {
            calendar.set(Calendar.ZONE_OFFSET, tz.getRawOffset());
            calendar.set(Calendar.DST_OFFSET, j >= 3 ? tz.getDSTSavings() : 0);
        }
    }

En omdat (volgens DateFormatSymbols) CET altijd 'hoort bij' CEST (useSameName is dus false) en CET eerder wordt genoemd (dus j ), worden de DST altijd op 0 gezet... Wellicht dat ik betere DateFormatSymbols kan maken?

[NMe]

ajvdvegt, zou je in het vervolg de edit-knop willen gebruiken als je wat toe te voegen hebt aan je topic? Om te beginnen leest dit niet erg makkelijk, en verder is het hier niet gewenst om continu je eigen topic omhoog te schoppen.