FeatureTransformer doesn't support xs:dateTime and related types

Chris Holmes added a comment - 13/Jul/05 1:12 PM Weird, I swore I committed this class which fixes it. Right before the branch. It needs DateUtil, which seems to be on both branches, but this never seems to have made it. I can't commit to svn, Paolo, could you see if this fixes things for you? Just put it in place of the old org.geotools.feature.type.TemporalAttributeType, it should make it so when toString is called on the attribute it returns the format we want. I figure no one actually wants the way it's done now, so this should be fine. If it works for you could you commit on branch 2.1.x and on trunk? Hopefully soon I'll sort out my svn problems.

Paolo Rizzi added a comment - 14/Jul/05 9:51 AM In fact I saw your previous comments and it looked strange not to find the fix... I'll check it tomorrow, if I'll be able to, or on next Monday. But i'm not sure if it has to be on TemporalAttributeType's shoulders to format the date in pure XML Schema format. After all formatting for XML should be FeatureTransformer's job. What do you think about this??? Also, looking at it briefly, it seems that with this fix TemporalAttributeType will continue to loose distinction between the three different cases: only date, only time, date and time, that can exist, with precise differences, in a RDBMS. We have many date and datetime fields in our DB, and we'll need to exchange data with other systems, so I'd like to think it out very well, because dates always give problems... I'll try to look at all the aspects of this matter to hopefully find a solution for all.

Chris Holmes added a comment - 14/Jul/05 11:26 AM Yeah, I agree that xml formatting should be the transformer's job. But none of the other attributeTypes have special cases for transforming to xml. And there's nobody that relies on it being the way format it is now, afaik. And it was easier to code this way. But I'm fine if you want to do the work to change it, or if it makes sense in light of your other changes. I did forget to mention that I didn't think the temporal did do the distinction between the cases. I'm happy with any solution you can come up with for it. Perhaps special subclasses of temporal for each. Whatever you think is appropriate, when I did it at the time I did notice that, but it didn't seem to be a pressing problem to the users who cared abou it.