How to parse date/time string into a date/time where "local" time can be extracted

I have a Java (11) application that can receive data that includes date/time values in the format:

yyyy-mm-ddThh:mm:ss.sssZ example: 2024-04-01T17:33:58.713Z

I need to be able to parse these strings into date/time objects and be able to work with and display the values in "local" time (e.g., US Central Time). I thought this would be fairly straightforward, but I’ve been trying lots of things that I thought would work, but do not.

Using the sample above, I would expect a "local" (assuming US Central) date/time that represents: April 1, 2024 at 12:33:58.713 CDT.

Note: I haven’t thought yet of how to handle "daylight" versus "standard" time. Perhaps the java.time library takes care of this?

I’ve tried using the LocalDateTime and ZonedDateTime parse(...) methods, as well as a DateTimeFormatter with and without a "zone" specified. I can’t get anything to do what I need.

Here is the class with the different things I’ve tried:

import java.time.LocalDateTime;
import java.time.ZoneId;
import java.time.ZoneOffset;
import java.time.ZonedDateTime;
import java.time.format.DateTimeFormatter;

public class DateTimeUtil {

  private static final DateTimeFormatter FORMAT = DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'");

  private static final DateTimeFormatter UTC    = DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'")
      .withZone(ZoneId.ofOffset("UTC", ZoneOffset.ofHours(0)));
  private static final DateTimeFormatter LOCAL  = DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'")
      .withZone(ZoneId.ofOffset("UTC", ZoneOffset.ofHours(-6)));

  public static LocalDateTime parse(Object object) {
    if (object == null) {
      return null;
    }

    return parse(object.toString());
  }

  public static LocalDateTime parse(String string) {
    if (string == null || string.isBlank()) {
      return null;
    }

    LocalDateTime dt = LocalDateTime.parse(string, FORMAT);
    return dt;
  }

  public static ZonedDateTime parseUTC(String string) {
    ZonedDateTime dt = ZonedDateTime.parse(string, UTC);
    return dt;
  }

  public static ZonedDateTime parseLocal(String string) {
    ZonedDateTime dt = ZonedDateTime.parse(string, LOCAL);
    return dt;
  }

}

Everything that I try just returns me a date/time object with the same time as from the source string. It has not been adjusted for the time zone difference.

Can someone give me an idea what I’m doing wrong or missing?

>Solution :

you’re making this way, way more complicated than it is:

ZonedDateTime utc = ZonedDateTime.parse("2024-04-01T17:33:58.713Z");
ZonedDateTime inNewYork = utc.withZoneSameInstant(ZoneId.of("America/New_York"));
System.out.println(utc);
System.out.println(inNewYork);

prints:

2024-04-01T17:33:58.713Z
2024-04-01T13:33:58.713-04:00[America/New_York]

Which, I gather, is what you want.

Some notes:

• withZoneSameLocal would you get you a ZDT in new york at 17:33.
• ZoneOffset.ofHours(-6) is a pointless abomination you should not be using. Offsets are low level constructs that have virtually no purpose in application-level code. You don’t want ‘the time at a place that is like UTC but 6 hours earlier’ because who knows where that is – politics are a thing and change timezones (if you don’t believe that, you should check the updates to tzdata. Or check the EU records, which have voted, though the implementation is for now delayed, to end daylight savings as a concept in all of the EU).
• EST is an abomination you should never use. For example, did you know that there is such a thing as ‘Eastern Standard Time’ in australia? It’s UTC+10; it’s usually abbreviated AEST but, as you might expect, australians don’t as a rule, include that ‘A’. You don’t call new york time ‘USEST’ either, do you? Besides, these 3-letter acronyms just don’t get the job done. Remember that EU decision? The EU decided all EU countries move away from daylight savings, but not which country goes where. The CET zone (Central European Time) is very large. Places like NL probably want to stick with summer time. But places like Poland probably with winter time. ‘CET’, in a few years, will be useless / ambiguous because it covers far too large an area. They haven’t been on the same time for most of history and are unlikely to remain the same timezone forever after. Also, if you don’t want to mess with anything outside the USA, may I present exhibit A: Arizona? Timezones are in Continent/BigCity form. Don’t use the others.