[JAVA] probleem met java.util.gregoriancalendar

[roeleboel]

Hallo,

ik ben tegen een probleem aangelopen met de klasse java.util.gregoriancalendar, met name het volgende:
31 augustus bestaat blijkbaar niet?

De code:

Java: TestDatum.java

GregorianCalendar date2 = new GregorianCalendar();

date2.setLenient(false);

date2.clear();
    
// zet de datum op 1 september, het jaar maakt echter niet uit voor dit probleem
date2.set(2007, 9, 1);

System.out.println("Originele dag: "+date2.get(Calendar.DAY_OF_MONTH));
System.out.println("Originele maand: "+date2.get(Calendar.MONTH));
System.out.println("Origineel jaartal: "+date2.get(Calendar.YEAR));

// ga 1 dag terug in de tijd        
date2.add(Calendar.DAY_OF_MONTH, -1);

System.out.println("Gewijzigde dag: "+date2.get(Calendar.DAY_OF_MONTH));
System.out.println("Gewijzigde maand: "+date2.get(Calendar.MONTH));
System.out.println("Gewijzigd jaartal: "+date2.get(Calendar.YEAR));

Als output krijg ik dan het volgende:
Originele dag: 1
Originele maand: 9
Origineel jaartal: 2007
Gewijzigde dag: 30
Gewijzigde maand: 8
Gewijzigd jaartal: 2007

Waar is 31 augustus naartoe?

Geprobeerde dingen:
* tijdzone gezet, geen effect
* datum rechtstreeks op 31 augustus zetten, geeft 1 september als output bij een "lenient calendar", bij "non-lenient" een exceptie
* al dan niet de date2.clear() gebruiken, geen effect

Iemand een idee wat ik hier over het hoofd zie?

[J2pc]

Maand is 0-based

Javadoc

MONTH

public static final int MONTH

Field number for get and set indicating the month. This is a calendar-specific value. The first month of the year is JANUARY which is 0; the last depends on the number of months in a year.

Maand 9 = Oktober,
-1 = 30 september

Niks geen probleem dus

[ Voor 3% gewijzigd door J2pc op 08-02-2008 15:21 ]

[roeleboel]

ah djees... zo iets over het hoofd zien...
Merci voor de snelle reactie!

[J2pc]

no problem Zijn van die rottige foutjes waar je heel lang overheen kunt kijken.

Maar ik zou echt de documentatie van sun downloaden.
Staat erg veel info in, en scheelt je veel tijd

Als je met eclipse programmeert kun je ze nog heerlijk integreren in je IDE ook.

[Confusion]

roeleboel schreef op vrijdag 08 februari 2008 @ 15:29:
ah djees... zo iets over het hoofd zien...

Als ik maatgevend ben, dan gaat dat je nog wel een paar keer gebeuren . Het is gewoon erg tegenintuitief.

[Standeman]

idd.. Ik ken maar weinig mensen die hier niet ingetrapt zijn.

[Feyd-Rautha]

De calendar-package in Java staat nogal bekend om zijn "vuile" API. Misschien moet je overwegen om de "Jodatime"-library te gebruiken. Deze zal heel waarschijnlijk zelfs in JDK 1.7 zitten.

[paulh]

Er zal vast een reden achter zitten maar het is inderdaad wel 1 van de meest idiote constructies in java. Ik ben er ook al een paar keer mee in de fout gegaan.

[flowerp]

Standeman schreef op vrijdag 08 februari 2008 @ 16:11:
idd.. Ik ken maar weinig mensen die hier niet ingetrapt zijn.

Inderdaad, heb er zelf ook regelmatig mijn hoofd aan gestoten. Nu staat bij al m'n code die met months te maken heeft overal een +1 en -1 al gelang naar de richting en met grote comments erbij "WARNING! JAVA HAS 0-BASED MONTHS!".

Jodatime werkt een stuk beter. Naar wat ik ervan begrepen heb komt deze niet rechtstreeks in JDK 7, maar zal de nieuwe date/time API er hevig door beïnvloed zijn.

[Robtimus]

Zelf gebruik ik met alle Calendar based berekeningen correcties.

Bv:

code:

int month = cal.get(Calendar.MONTH) - Calendar.JANUARY + 1; // 1 based
int weekday = cal.get(Calendar.DAY_OF_WEEK) - Calendar.SUNDAY; // 0 based

[Verwijderd]

Ik vermoed dat de keuze is gemaakt omdat maanden ook namen hebben. De dag van de maand en het jaar niet direct. Met een 0-based maand index kun je makkelijk een array met namen (van maanden) koppelen aan de waarde die binnenkomt van de API.

[Verwijderd]

Verwijderd schreef op zondag 10 februari 2008 @ 13:54:
Ik vermoed dat de keuze is gemaakt omdat maanden ook namen hebben. De dag van de maand en het jaar niet direct. Met een 0-based maand index kun je makkelijk een array met namen (van maanden) koppelen aan de waarde die binnenkomt van de API.

Dat zal inderdaad wel de reden zijn. En ik kan me voorstellen dat het in een paar gevallen nuttig is. Maar de problemen die daarmee gecreëerd zijn wegen volgens mij absoluut niet op tegen de voordelen.

Trouwens, als Java 7 1-based maanden gaat gebruiken gaat het pas helemaal feest worden, dan hangt het af van welke Java versie je gebruikt...

[Remus]

Verwijderd schreef op zondag 10 februari 2008 @ 18:04:
[...]

Dat zal inderdaad wel de reden zijn. En ik kan me voorstellen dat het in een paar gevallen nuttig is. Maar de problemen die daarmee gecreëerd zijn wegen volgens mij absoluut niet op tegen de voordelen.

Trouwens, als Java 7 1-based maanden gaat gebruiken gaat het pas helemaal feest worden, dan hangt het af van welke Java versie je gebruikt...

Er komt gewoon een nieuwe klasse bij, de bestaande Calendar-implementaties zoals GregorianCalendar zullen gewoon 0-based blijven.

[momania]

Niet maar 1 nieuwe klasse, een complete API

Zie: https://jsr-310.dev.java.net/

Afgelopen Javapolis daar een snel overview van gekregen tijdens een presentatie. Je ziet er idd heel veel invloeden van Jodatime in terug komen en enige dat ik kan zeggen is: eindelijk

[SchizoDuckie]

Het leuke is dat dankzij java exact deze ranzigheid in het JavaScript Date Object in je browser zit Ben ik ook al een paar keer mee de mist in gegaan. Het belachelijke is dat alleen de maand op 0-based gaat en dag weer niet. It still boggles my mind

[Robtimus]

Over de arrays: weekdagen beginnen by Calendar.SUNDAY, wat dus wel 1 is...
Dat is ook apart als je werkt met java.text.DateFormatSymbols; deze class heeft methods om String[]s te returnen voor zowel de maand namen als de weekdag namen. Het ene array heeft 13 elementen, waarvan de laatste leeg. De eerste heeft 8 elementen, waarvan de eerste leeft. Hoezo inconsistent?