java helloworld calendar problem

[aslakhellesoy]

From mailing list: https://groups.google.com/group/cukes/browse_thread/thread/65578cd796fd31f5/f0a489809322a0e7?lnk=gst&q=JChronic+step+fails+running+java-helloworld+example#f0a489809322a0e7

I get the following error running the tests on the java-helloworld example (using Java 1.6 in the UK)

It boils down to the following fields being different: firstDayOfWeek, minimalFirstDaysInFirstWeek and WEEK_OF_MONTH

Any clues, anyone?

java.lang.AssertionError: expected:<java.util.GregorianCalendar[time=1354579200000,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="Europe/London",offset=0,dstSavings=3600000,useDaylight=true,transitions=242,lastRule=java.util.SimpleTimeZone[id=Europe/London,offset=0,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2012,MONTH=11,WEEK_OF_YEAR=49,WEEK_OF_MONTH=2,DAY_OF_MONTH=4,DAY_OF_YEAR=339,DAY_OF_WEEK=3,DAY_OF_WEEK_IN_MONTH=1,AM_PM=0,HOUR=0,HOUR_OF_DAY=0,MINUTE=0,SECOND=0,MILLISECOND=0,ZONE_OFFSET=0,DST_OFFSET=0]> but was:<java.util.GregorianCalendar[time=1354579200000,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="Europe/London",offset=0,dstSavings=3600000,useDaylight=true,transitions=242,lastRule=java.util.SimpleTimeZone[id=Europe/London,offset=0,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]],firstDayOfWeek=2,minimalDaysInFirstWeek=4,ERA=1,YEAR=2012,MONTH=11,WEEK_OF_YEAR=49,WEEK_OF_MONTH=1,DAY_OF_MONTH=4,DAY_OF_YEAR=339,DAY_OF_WEEK=3,DAY_OF_WEEK_IN_MONTH=1,AM_PM=0,HOUR=0,HOUR_OF_DAY=0,MINUTE=0,SECOND=0,MILLISECOND=0,ZONE_OFFSET=0,DST_OFFSET=0]>

Can probably be fixed by setting time zone and locale

[arjunsol]

Would an assertion on the milliseconds not suffice?

assertEquals(day.getTimeInMillis(), laundryDate.getTimeInMillis());

[aslakhellesoy]

It would make the test pass, but I'd rather get to the bottom of why the calendar timezones and/or locales are different.

[aslakhellesoy]

Both Chronic and Cucumber create java.util.Calendar using the default time zone, but the Locale they use is different.

Chronic uses the default Locale, while Cucumber picks a Locale based on the gherkin file's language (the #language header). If no #language header is specified, the language is en, which causes it to use new Locale("en").

The default Locale on a typical UK machine is not new Locale("en"), which is the same as Locale.ENGLISH, but rather new Locale("en", "GB"), which is the same as Locale.UK. These are not the same. What's happening is essentially this:

Date date = new Date();

Calendar en = Calendar.getInstance(Locale.ENGLISH);
Calendar uk = Calendar.getInstance(Locale.UK);

en.setTime(date);
uk.setTime(date);

assertEquals(en, uk); // fails besause firstDayOfWeek and minimalFirstDaysInFirstWeek and WEEK_OF_MONTH are different.

An interesting way to make the small test above pass is to do this:

Calendar en = Calendar.getInstance(Locale.ENGLISH);
Calendar uk = Calendar.getInstance(Locale.US);

In short, in the US, weeks start on Sunday and in the UK (and most of Europe) it starts on Monday.

Chronic aside, this makes me think that the decision to make Cucumber create a locale based on the (default) en language is OK for Americans, but not OK for Brits.

I can think of two ways to address this. One way would be to allow Brits to say #language=en-GB in their gherkin files. Another option would be to set the default Locale in some sort of settings (see #330). If one is set, use that, otherwise use the Locale derived from #language.

As for the example, I'll fix it by just comparing the Calendars' millis now that I understand why this was failing.

Comments and suggestions welcome!

[arjunsol]

edited: redundant comment.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.