KML Time template does not work anymore due to XSDateTimeBinding changes

We can change the KML code to avoid building the calendar, but I'm wondering if other code might have been broken by the XSDateTimeBinding implementation changes?

The old code in XSDateTimeBinding used to be:

public String encode(Object object, String value) {
        Calendar datetime = (Calendar) object;

        return DatatypeConverterImpl.getInstance().printDateTime(datetime);
    }

while the new code is:

final Date timestamp = (Date) object;// lets catch up java.util.Date as well as
                                             // java.sql.Timestamp
        Calendar cal = Calendar.getInstance(TimeZone.getTimeZone("GMT"));
        cal.clear();
        cal.setTimeInMillis(timestamp.getTime());
        return DatatypeConverterImpl.getInstance().printDateTime(cal);

The KML call results in a ClassCastException

Btw, having attributes as Calendar is not forbidden in our object model, the shapefile data store in particular can write them out, it checks if the object value is a Date or a Calendar and acts consequently.

Yeah... this was my worry when making the change, which is why I insisted that full tests (including cite) were run... but it seems not everything was caught, side affect of the poor test coverage in KML i suppose.

I guess a good way forward would be to have the bindings handle the calendar case, rather then straight cast to Date. A good measure for backwards compatibility. Do we have a converter that properly converts from Calendar to Date? If so it should be easy enough, just one liners in each of the bindings.

Gabriel?

I don't think we have it, but writing one, or just add the manual conversion in XSDateTimeBinding, should be trivial.
I agree having XSDateTimeBinding just call Converters.convert(whateverObject, Date.class) would look cleaner

Upping priority as it is a regression on the stable series

Ah, forgot that Gabriel is away (vacation right?)

Hello. Yeah unfortunately on vacation right now so no dev env at hand.
But feel free to replace the direct cast to a Converters call. AFAIK there is a converter for Calendar <--> Date.
Also, afaict it´s ok that feature attributes are Calendar like in the shapefile case. It just looks like calling DatatypeConverterImpl.getInstance().printDateTime() doesn´t go through the whole converting cycle Encoder does. So GML encoding should already be safe. By using Converters in the binding as you propsed we should be coevred either case.

Cheers,
Gabriel

I've found out the converter was already in place. Adding test cases both in gt2 and in geoserver

Fixed in GeoTools, added one kml time template test to make sure it does not come back (at least, not in the current form)

Mass transition all resolved issue that did not see any further comment in the last month to closed status