Add conversion to old java.util.Calendar

[MenoData]

Enhance the class TemporalType by a new constant:

public static final TemporalType<java.util.Calendar,ZonalDateTime> JAVA_UTIL_CALENDAR;

[forrestguice]

I think this would be a nice convenience.

What is best approach for going from java.util.Calendar to a PlainDate? or from Moment to a properly zoned java.util.Calendar?

Forgive me if this is really straightforward (dumb question). I need to be confident I'm using it right. For example, I've got a snippet that looks like... How to complete it?

public Calendar getCivilSunriseCalendarForDate( Calendar date )
{
    PlainDate d = null;   // todo: convert from Calendar (has TimeZone)
    ChronoFunction<CalendarDate, Moment> civilRise = calculator.sunrise(Twilight.CIVIL);
    Moment moment = d.get(civilRise);
    PlainTimestamp timeStamp = moment.toZonalTimestamp(timezone);
    return null;             // todo: convert back to Calendar?
}

[MenoData]

Thanks for your interest. First let me explain some things about the calendar date input (indicated by first generic type parameter CalendarDate).

Its date value (expressed by year, month, day-of-month) has to be interpreted as local calendar date at given geographical longitude. The algorithms I have implemented so far use this calendar date at noon time and longitude to calculate an approximation of sunrise/sunset before refining it up to minute precision. Important is to understand that the timezone is not really in play during this first step of calculation. The date is like a longitudinal date, but the longitudinal zone offset is generally not the same as civil timezone offset. Of course, if we choose a timezone which yields finally the same calendar date at given geographical longitude then we are fine (especially at noon time). And if the input to the suntime-calculators in Time4J is just a plain date (for example the gregorian type PlainDate) then there is absolutely no problem (civil date = longitudinal date at noon).

Just for the records: This subtile difference between longitudinal date and civil-timezone-related date is relevant for example in the issue raised in the suntime-library of Mike Reedell. And sure, the resulting sunset can happen on another civil date than the local date for which the sunset was searched/wanted. This is simply due to the difference between longitudinal offset and civil tz-offset.

So you might ask when Time4J applies the civil timezone? It is the last step after you have already calculated the sunrise/sunset-event as Moment. You can convert the moment to a local civil date and time using the civil timezone (by methods like toZonalTimestamp(...). So the civil timezone is not related to the input but can be applied on the output of sunrise/sunset-calculation.

So let's now return to the original question how to convert java.util.Calendar.

Your interface SuntimesCalculator expects an input of type java.util.Calendar (which has indeed a timezone). I would ignore the supplied timezone and just extract the values of year, month and day-of-month when passing/converting the Calendar-input to Time4J-calculator. This is based on the reasonable assumption that the timezone is chosen such that it approximates the longitudinal offset of given location. Otherwise it becomes awkward. Alternative conversion strategy in context of your SuntimesCalculator-interface handling your input (really a special case not covered by the suggested new TemporalType-constant in this issue):

• convert java.util.Calendar to Moment (straight-forward via the intermediate type java.util.Date)
• then convert the moment to a PlainDate using the longitudinal offset at given geographical longitude (see the method ZonalOffset.atLongitude(...).

Maybe this is the safest approach to defend against users who chose let's say "America/New_York" as timezone and look for the sunrise-event anywhere in Australia...

[MenoData]

An extra conversion between the classes java.util.TimeZone and net.time4j.tz.Timezone was also added.