On 25 Mar 2013, at 22:04, Riccardo Mottola wrote: > Hi, > > Richard Frith-Macdonald wrote: >> Have you tried the current testcase? A couple of days ago I added a call to >> try to ensure that the calendar was in a consistent state by specifically >> setting the first week length before the test. >> What value does the call to -weekOfMonth return? > Running base/NSCalendar/features-10-7.m... > Start set: features-10-7.m:21 ... NSCalendar 10.7 features > 2013-03-25 08:02:47.163 features-10-7[6840] No local time zone specified. > 2013-03-25 08:02:47.163 features-10-7[6840] Using time zone with absolute > offset 0. > Failed test: features-10-7.m:35 ... -weekOfMonth returns the correct > week > Passed test: features-10-7.m:36 ... -weekOfYear returns the correct week > > this is my output, notice the warnings before! But the timezone shouldn't > interfere I hope. > > It return month "6" instead of "5" as the test wants.
Well I think I have it fiugured out ... andit seems we have a more extensive/general problem. For the first time I looked in detail at how the NSCalendar code works internally, and the problem is that it uses an ICU calendar to store internal state, but then resets that calendar in many places (losing the stored state). So we may set the correct week day information (what day the week starts on and how many days of the week mutst be in a month for the week to be considered part of the month), but then because the ICU calendar is reset, we throw that information away again. As far as I can see, fixing this requires adding instance variables to store this state outside the ICU calendar ... _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
