Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support ZonedDateTime [DATACMNS-1577]

Closed
spring-projects-issues opened this issue Sep 3, 2019 · 2 comments
Closed

Support ZonedDateTime [DATACMNS-1577] #2003

spring-projects-issues opened this issue Sep 3, 2019 · 2 comments
Assignees
Labels
in: mapping status: declined type: enhancement

Comments

@spring-projects-issues
Copy link

spring-projects-issues commented Sep 3, 2019

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
Copy link
Author

spring-projects-issues commented Sep 3, 2019

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
Copy link
Author

spring-projects-issues commented Sep 3, 2019

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

@spring-projects-issues spring-projects-issues added status: declined type: enhancement in: mapping labels Dec 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: mapping status: declined type: enhancement
Projects
None yet
Development

No branches or pull requests

2 participants