You can implement your own add rules, by examining and modifying the setYear method in BasicGJChronology. Line 174 of http://joda-time.svn.sourceforge.net/viewvc/joda-time/trunk/JodaTime/src/java/org/joda/time/chrono/BasicGJChronology.java?revision=960&view=markup
A new Chronology implementation can also be implemented, which uses different rules for the leap day. Roy van Rijn wrote: > Wow, that sounds kind of ugly, either way. > > There isn't a ISO/standard for calculating and handling leap years? > > We find it kind of disturbing there are days different in our > calculations now that we've switched from Java's Date/Time to Joda > Time. I've always seen Joda Time as a framework with easier API but > similair calculations, being a 'quality replacement'. But with > financial European 360-day calculations the difference between Feb 28 > and Mar 01 can de three financial days, for us this is problematic. > > Can I find a summary somewhere online with the differences compared to > Java's Date/Time API? This would be very handy when people are > thinking about changing their Date/Time API. This might mean we have > to switch back :-( > > Also I wonder what this will do to JSR-310. I've tested JSR-310 and it > contains the same feature/discrepantion. If the general idea still is > that Java's Date/Time will be gutted and JSR-310 will underneath be > used... this discrepantion will break the backwards compatibility. > > On Wed, Oct 7, 2009 at 4:44 PM, Brian S O'Neill <bro...@gmail.com> wrote: > >> When adding a field would produce a bogus date, Joda-Time makes an >> adjustment to the smallest field to correct it. If Feb 29 is illegal, >> two choices are possible: Feb 28 and Mar 1. Selecting Mar 1 causes two >> fields to adjust, the day of month and month of year. Feb 28 introduces >> less error -- only the day of month changes. >> >> We also considered choosing the error adjustment based on the direction >> of the change. That is, adding one year produces Mar 1, but subtracting >> would produce Feb 28. This might be more confusing, and it too might be >> opposite of what someone expects. No matter what we choose to use in >> Joda-Time, there's always a use case where it is not what someone expects. >> >> One reason why the Calendar class can get away with a Mar 1 >> representation for Feb 29 is because internally, the Calendar still >> thinks its Feb 29. It just displays it as Mar 1. If you subtract a year, >> you'll be back to where you started at Feb 29. With Joda-Time, >> subtracting back will yield Feb 28. This is because DateTime class >> always holds a precisely defined date. For this reason, if you're adding >> multiple years, (or any field for that matter) don't do one at a time. >> >> roy.van.r...@gmail.com wrote: >> >>> Oops, just noticed I'm using Dutch/European notation of days, to make >>> it clear: >>> -- >>> >>> Well, you can't just always add 365 days, because some years >>> (leapyears) have 366 days. >>> >>> The point is, if you add a year and you are in a leapyear before Feb >>> 29 you have to add 366 to get to the correct day the next year (Feb 20 >>> 2004 + 366 = Feb 20 2005). >>> >>> And after Feb 29 you have to add 365 days to get to the correct day >>> (Mar 20 2004 + 365 = Mar 20 2005). >>> >>> But what should be added when you are ON Feb 29? For that I'm not >>> quite sure... it seems Java and Joda Time disagree on this. And I >>> don't have the ISO to confirm what the correct method is. >>> >>> >>> Op 7 okt. 2009 10:19 schreef roy.van.r...@gmail.com: >>> >>>> Well, you can't just always add 365 days, because some years >>>> >>> (leapyears) have 366 days. >>> >>>> The point is, if you add a year and you are in a leapyear before >>>> >>> 29-02 you have to add 366 to get to the correct day the next year >>> (20-02-2004 + 366 = 20-02-2005). >>> >>>> And after 29-02 you have to add 365 days to get to the correct day >>>> >>> (20-03-2004 + 365 = 20-03-2005). >>> >>>> But what should be added when you are ON 29-02? For that I'm not >>>> >>> quite sure... it seems Java and Joda Time disagree on this. And I >>> don't have the ISO to confirm what the correct method is. >>> >>> ------------------------------------------------------------------------ >>> >>> ------------------------------------------------------------------------------ >>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >>> is the only developer event you need to attend this year. Jumpstart your >>> developing skills, take BlackBerry mobile applications to market and stay >>> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >>> http://p.sf.net/sfu/devconference >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Joda-interest mailing list >>> Joda-interest@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/joda-interest >>> >>> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> Joda-interest mailing list >> Joda-interest@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/joda-interest >> >> > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Joda-interest mailing list > Joda-interest@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/joda-interest > > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Joda-interest mailing list Joda-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/joda-interest
