Add toLocalDate to CalendarUtils

[asgh]

Using an Instance to create a LocalDate from a Calendar does not work on dates before the Gregorian/Julian cutover.

So use this code instead, and add tests for years before the cutover and after.

[coveralls]

Coverage increased (+0.0003%) to 94.915% when pulling 9834ab1 on asgh:master into b59c7bf on apache:master.

[asgh]

The failing tests appear to be from other code, not the new code in the pull request.

[garydgregory]

@asgh

Would you please rebase on master?

[asgh]

@garydgregory

Done.

[garydgregory]

@asgh
Thank you for the update. Please run 'mvn' by itself before you push to catch all errors.

[asgh]

@garydgregory

I don't have mvn on this computer, I hope my last commit fixed things, if not I'll have to work on it a little later.

[garydgregory]

I'm not sure the implementation is correct. The following fails with this PR:

    @ParameterizedTest
    @MethodSource("java.util.TimeZone#getAvailableIDs()")
    public void testToLocalDate(final String id) {
        final TimeZone timeZone = TimeZone.getTimeZone(id);
        final Calendar calendar = new GregorianCalendar(timeZone);
        // sanity check
        assertEquals(LocalDateTime.ofInstant(calendar.toInstant(), timeZone.toZoneId()).toLocalDate(), new CalendarUtils(calendar).toLocalDate());
        // actual test
        calendar.setTimeInMillis(-27078001200000L);
        assertEquals(LocalDate.of(1111, Month.DECEMBER, 1), new CalendarUtils(calendar).toLocalDate());
        calendar.setTimeInMillis(1614700215000L);
        assertEquals(LocalDate.of(2021, Month.MARCH, 2), new CalendarUtils(calendar).toLocalDate());
    }

[garydgregory]

@asgh
Please rebase on git master to pick up the latest from this class.

[asgh]

@garydgregory

I'm not sure the implementation is correct. The following fails with this PR:

That's exactly why I added this!

Dealing with local dates that cross timezones is a mess, LocalDate specifically has no timezone, the other way also does not correctly handle early dates. It's the other code that is incorrect.

If you feel it's really important I can try to dive into the debugger and find where your pr goes wrong, but I already basically know where it will fail.

You have to be careful about the timezone and the time you pick if you want to add such a test - if your local timezone, and GMT, have different dates for the time you picked (I assume current time), your test will fail.

The point of this function is to create a LocalDate specifically using the current timezone.

[garydgregory]

Hello @asgh,

Thank you for your reply and update.

I don't think the implementation is correct because it does not take into account the Calendar's time zone.

You should be able to see this if you test with time zones and adjust the test as in my example test using:

    @ParameterizedTest
    @MethodSource(TimeZonesTest.TIME_ZONE_GET_AVAILABLE_IDS)

See also the other tests in this class.

TY!

[asgh]

@garydgregory

I'm really not following you. For this to be wrong this.getDayOfMonth() would have to be wrong. Are you saying that function returns the wrong day of the month?

And the entire point is that LocalDate doesn't have a timezone. I'm only setting the timezone in the test so that it correctly converts the UnixTime into a Month and Day (otherwise it could vary +- a day depending on what timezone you pick).

If you look at the actual function in the code there is no timezone there are all.

I will run your assert with some sample data to try to explain.