-1

I want to migrate this code:

private Resource getRegistrations(DateTime startDate) {   
    DateTime pageStartDate = (startDate == null) ? null : startDate.withZoneRetainFields(DateTimeZone.UTC);    
    return ........;
  }

to this:

private Resource getRegistrations(OffsetDateTime startDate) {
    OffsetDateTime pageStartDate = (startDate == null) ? null : startDate.atZoneSameInstant(ZoneId.of("UTC")).toOffsetDateTime();
    return null;
  }

Is this the proper way atZoneSameInstant(ZoneId.of("UTC")).toOffsetDateTime(); To set the time zone?

Peter Penzov
  • 1,126
  • 134
  • 430
  • 808
  • Using Joda-Time `withZoneRetainFields()` is unusual. Are you sure it’s what you always wanted? Could it be that it just happens to give you the expected result because in practice the incoming `DateTime` was already in UTC? – Ole V.V. Apr 17 '23 at 13:35
  • Stop posting the [same question](https://stackoverflow.com/q/76028526/839733) repeatedly. – Abhijit Sarkar Apr 19 '23 at 11:45

1 Answers1

2

No.

withZoneRetainFields keeps the 'fields' - year, month, day, hour, minute - those are fields. By changing the timezone, the first snippet means that the timestamp returned is not the same as the input value. Given the name getRegistrations it strongly sounds to me like the first code is wrong. This happens: You are refactoring, and you found a bug.

The second snippet maintains the same instant. In other words, if you have, say, '5 o'clock in the afternoon, december 20th, in london' and you use atZoneSameInstant to get a time in the Europe/Amsterdam zone, you'd get 6 o clock back (because when it's 5 o'clock in london, it's 6 in amsterdam, amsterdam is in a time zone 1 hour ahead of britain).

The first snippet would give you 5 o'clock in amsterdam which is in fact 1 hour earlier.

Note that OffsetDateTime is the one you should almost never use. You probably want ZonedDateTime. The problem with offsets is that they do not map onto any reckoning at all. Computers don't like offsets (they like millis-since-an-epoch), and humans don't use offsets, they use timezones. There's no difference if it's a zone that doesn't have daylight savings, but many do.

Your variable is also wrong. Why is a DateTime object called pageStartDate?

If you are just interested in dates, then use LocalDate. If it's actually about a specific moment in time by human reckoning, use ZonedDateTime. If it's about computer systems / raw comparisons (you just want to know which event amongst a whole bunch of em was 'earlier' than another, you don't really care about which date it was on, for example), then use java.time.Instant.

`ZonedDateTime pageStart

rzwitserloot
  • 85,357
  • 5
  • 51
  • 72
  • Let me give you some additional clarification what I'm doing: The original filed that I have is using this: https://stackoverflow.com/questions/75428799/cannot-resolve-method-withzone-in-offsetdatetime I want to migrate `org.jadira.usertype.dateandtime.joda.PersistentDateTime` (org.joda.time.DateTime) to `java.time.OffsetDateTime` Do you think am I using `OffsetDateTime` properly or there is a better alternative? – Peter Penzov Apr 16 '23 at 18:32
  • jodatime `withZone` translates to `atZoneSameInstant`, and `withZoneRetainFields` becomes `withZoneSameLocal`. jodatime's `DateTime` mostly becomes `ZonedDateTime`, it's not quite a 1v1 translation, but that's a much, much better option than `OffsetDateTime`. – rzwitserloot Apr 16 '23 at 18:54
  • ok, can you guide me how I have to edit the original code when I use `ZonedDateTime`? – Peter Penzov Apr 16 '23 at 18:58
  • There aren't anywhere near enough details in your post to do such a thing. What more do you need to know? The original snippet changes the instant in time, only you know if that is correct or not. If it is, use `withZoneSameLocal`, if it is not, use `withZoneSameInstant` and make sure the rest of the team knows you also fixed a bug as part of your refactor. Replace `OffsetDateTime` with `ZonedDateTime`. If there is an issue with doing that, post a new question explaining why ODT works when ZDT doesn't. – rzwitserloot Apr 16 '23 at 19:03