Support ZonedDateTime [DATACMNS-1577]

[spring-projects-issues]

Herman Bovens opened DATACMNS-1577 and commented

Since there is no converter supplied for ZonedDateTime, developers using this Java 8 type always need to create these: 

class ZonedDateTimeReadConverter : Converter<Date, ZonedDateTime>
{
    override fun convert(date: Date): ZonedDateTime =
            date.toInstant().atZone(ZoneOffset.UTC)
}
 
class ZonedDateTimeWriteConverter : Converter<ZonedDateTime, Date>
{ 
    override fun convert(zonedDateTime: ZonedDateTime) =
            Date.from(zonedDateTime.toInstant()) 
}

And then they need to register these as custom conversions, for example in a Spring Boot Project using Spring Data MongoDb:

@Configuration
@EnableReactiveMongoRepositories
class MongoConfiguration
{
    @Bean
    fun customConversions(): MongoCustomConversions =
            MongoCustomConversions(listOf(ZonedDateTimeReadConverter(),
                                          ZonedDateTimeWriteConverter()))
}

The framework could supply those instead and have them registered by default

---

Affects: 2.2 RC2 (Moore)

[spring-projects-issues]

Oliver Drotbohm commented

This implementation is broken as it loses the original time zone. That's exactly the reason why there's no OOTB implementation to handle time zone aware date/time types. We recommend to rather store zone-less date/time instances alongside the original time zone (if the latter is needed at all, which in most cases it shouldn't be). That in turn then has to be implemented on a different level of store-specific abstraction as it usually requires more than one field to write to which then raises the question how that affects sortability, which field names to use etc.

As you can see this is much less trivial than on might originally think, which in turn is the reason why no simple solution to it exists :)

[spring-projects-issues]

Herman Bovens commented

Oliver Drotbohm OK, I see.  A database like MongoDB stores timestamps in UTC and will therefore always lose the time zone.  So in that case it would be expected.  But indeed, if you're only interested in storing the timestamp regardless of the time zone, you should use Instant in the data model and convert to the proper time zone when needed.  I simply overlooked the possibility to use Instant as an alternative to falling back to java.util.Date