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 :)
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