We Keep Coding

Converting Joda DateTime to JavaTime

I am trying to update my existing elasticsearch springboot project and as the source code is fairly old it still uses joda time. Now I have to upgrade all the functions of Joda time to java time. Now in the project We use Date Time of Joda Time
Code Sample for Joda Time
DateTime target = new DateTime(String targetDate, UTC);
We use this function currently in our code to convert a String to Date.
Using this function the String
2022-10-01T00:00:00.000
gets converted to
2022-10-01T00:00:00.000Z
I am trying to replicate the same in java time.
I tried to parse the targetDate using OffsetDateTime and ZonedDateTime but both gave me errors.
Text '2022-10-01T00:00:00.0000' could not be parsed at index 24
After some attempts I was able to move forward by using LocalDateTime
LocalDateTime target = LocalDateTime.parse(String targetDate);
Which was able to parse the String but the format was not correct the format I got was
2022-10-01T00:00Z
I also tried using the formatter with LocalDateTime
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSS'Z'");
LocalDateTime target= LocalDateTime.parse(targetDate,formatter);
But This Still gave me the Error
Text '2022-10-01T00:00:00.0000' could not be parsed at index 24
Now I am a bit confused regarding this.
Any help is appreciated.
And Please correct me if my way of asking question or formatting is wrong at any point still new to this.
Regards.
EDIT: Sorry for the confusion but as pointed out I should have mentioned that I want the returned value as the java.time datetime object and not a String so that I can further perform some logic on it. Sorry for this.
Thanks and Regards

The String "2022-10-01T00:00:00.000" can be parsed to a LocalDateTime because it only consists of year, month of year, day of month, hour of day, minute of hour, second of minute and fractions of second.
Your desired output String "2022-10-01T00:00:00.000Z" represents the same values plus an offset, the Z for Zulu time, which basically means UTC.
If you want to add an offset to the input String with java.time, you can parse it to a LocalDateTime and then append the desired offset, which results in an OffsetDateTime. You can print that in a desired format using a DateTimeFormatter, either use a prebuilt one or define one yourself.
Here's a small example:
public static void main(String[] args) {
// input value
String dateTime = "2022-10-01T00:00:00.000";
// parse it and append an offset
OffsetDateTime odt = LocalDateTime.parse(dateTime).atOffset(ZoneOffset.UTC);
// define a formatter that formats as desired
DateTimeFormatter dtf = DateTimeFormatter.ofPattern("uuuu-MM-dd'T'HH:mm:ss.SSSX");
// and print the OffsetDateTime using that formatter
System.out.println(odt.format(dtf));
}
Output:
2022-10-01T00:00:00.000Z
Clarification update:
There is just a single instance OffsetDateTime in my example with the following values:
year (2022)
month of year (10)
day of month (1)
hour of day (0)
minute of hour (0)
second of minute (0)
franctions of second (0)
offset (UTC / +00:00)
This instance of OffsetDateTime can be used for calculations (e.g. add/subtract days, months or other units) and it can be formatted as String. It also has a toString() method we don't have under control, but is used if you don't explicitly format it.
The following lines (first one is the last of my example above) show some different usages:
// print formatted by the DateTimeFormatter from the above example
System.out.println(odt.format(dtf));
// print the object directly, implicitly using its toString()
System.out.println(odt);
// print formatted by a prebuilt DateTimeFormatter (several are available)
System.out.println(odt.format(DateTimeFormatter.ISO_OFFSET_DATE_TIME));
// print with a formatter that uses locale dependant expressions like month names
System.out.println(odt.format(
DateTimeFormatter.ofPattern("EEEE, MMM dd HH:mm:ss xxx",
Locale.ENGLISH)));
the last one also uses a different representation for UTC: instead of Z it shows the offset in hours and minutes.
Output:
2022-10-01T00:00:00.000Z
2022-10-01T00:00Z
2022-10-01T00:00:00Z
Saturday, Oct 01 00:00:00 +00:00

How do I convert any Timestamp string to a single Format in Java

I want to convert the timestamps which are in different formats to one format
I want to convert following timestamps to single format
Time Stamp 1 : 2022-08-17T18:28:07.288496+05:30
Time Stamp 2 : 2022-10-27T13:17:47.987736542Z
to
yyyy-MM-dd'T'HH:mm:ss format
I have tried using DateFormatter of Java but it gives ParseException. Also used SimpleDateFormatter but was getting same exceptions.
Please suggest package or methods for the same.
Edit : Code I used for conversion
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss");
LocalDateTime localDateTime = LocalDateTime.parse(timestamp, formatter);
System.out.println(localDateTime);

Using java.time here is a good idea compared to java.util.Date, Calendar and so on, but you have to use specific classes that match the information inside a String that represents a datetime or timestamp.
In your case, the String contains the following information:
year
month of year
day of month
hour of day
minute of hour
second of minute
fractions of second
offset from UTC
In particular, it's the last one (offset from UTC) which makes your attempt fail because you (1) don't consider it in the pattern of the DateTimeFormatter and (2) you use a class that cannot store it (LocalDateTime is not able / designed to hold information about a zone or an offset.
Having Strings with an offset can be stored in / parsed to OffsetDateTimes, if they are ISO formatted (as your examples are), you don't even need to apply a custom DateTimeFormatter. You can simply call OffsetDateTime.parse(String).
You can then define a desired format for an output by creating a custom DateTimeFormatter and apply it in OffsetDateTime.format(DateTimeFormatter).
Here's an example:
public static void main(String[] args) {
// example Strings (your ones)
String timestampOne = "2022-08-17T18:28:07.288496+05:30";
String timestampTwo = "2022-10-27T13:17:47.987736542Z";
// directly parse them to get instances of OffsetDateTime
OffsetDateTime odtOne = OffsetDateTime.parse(timestampOne);
OffsetDateTime odtTwo = OffsetDateTime.parse(timestampTwo);
// prepare a formatter for your desired output
DateTimeFormatter dtfOut = DateTimeFormatter.ofPattern("uuuu-MM-dd'T'HH:mm:ss");
// and print the values of the OffsetDateTimes formatted by that DateTimeFormatter
System.out.println(odtOne.format(dtfOut));
System.out.println(odtTwo.format(dtfOut));
}
Output:
2022-08-17T18:28:07
2022-10-27T13:17:47

How to format time objects in Java into the correct timezone

I want to use the Java Time API to get the central Europen summer time (CEST) and format it correctly. I have the following code:
LocalDateTime localDateTime= LocalDateTime.now();
DateTimeFormatter myFormatObj = DateTimeFormatter.ofPattern("dd-MM-yyyy HH:mm:ss");
localDateTime.format(myFormatObj);
ZoneId europeBerlin = ZoneId.of("Europe/Berlin");
ZonedDateTime zonedDateTime = ZonedDateTime.of(localDateTime, europeBerlin);
The command zonedDateTime.toString()leaves to the following output:
2020-09-27T08:42:33.660+02:00[Europe/Berlin]
But I would like to have an output as specified before in the DateTimeFormatter ("dd-MM-yyyy HH:mm:ss"). I have already formatted the localDateTime into this format and now I just want to get the CEST time. How can I do that? I'd appreciate every comment.

Please note that date-time objects from the Java Time API are immutable. Therefore, whenevery you want to modify an existing date-time instance, a new fresh copy is returned, leaving the old one untouched.
Also, a minor optimization: DateTimeFormatter is thread-safe. Thus, there is no need to construct a new instance every time, since the format is constant. You could declare it at the top like this:
private static final DateTimeFormatter FORMATTER;
static {
FORMATTER = DateTimeFormatter.ofPattern("dd-MM-yyyy HH:mm:ss");
}
To print a formatted String, use the following:
LocalDateTime localDateTime = LocalDateTime.now();
ZoneId europeBerlin = ZoneId.of("Europe/Berlin");
ZonedDateTime zonedDateTime = ZonedDateTime.of(localDateTime, europeBerlin);
// please note that #format has a return value
// originally, you called 'localDateTime.format(myFormatObj);' while ignoring
// the return value
String formatted = FORMATTER.format(zonedDateTime);
System.out.println(formatted); // e.g. 27-09-2020 11:44:27
Edit 1: Regarding thread-safety
Thread-safety refers to when an object can safely be used by mutliple threads concurrently, without breaking internals of the class. If a class is thread-safe, you can call it from mutliple threads at the same time (therefore you do not need to create a new instance every time, but only one). If a class is not thread-safe, a new instance is needed for each thread.

DateTimeFormatter myFormatObj = DateTimeFormatter.ofPattern("dd-MM-yyyy HH:mm:ss");
ZoneId europeBerlin = ZoneId.of("Europe/Berlin");
ZonedDateTime zonedDateTime = ZonedDateTime.now(europeBerlin);
String formattedDateTime = zonedDateTime.format(myFormatObj);
System.out.println(formattedDateTime);
Output when running in UTC time zone just now:
27-09-2020 20:33:53
We got the Berlin time (not the UTC time).
What went wrong in your code?
Two things:
LocalDateTime.now() gives you the current time in the default time zone of the JVM. It seems that this was not Eurpoe/Berlin (perhaps it was UTC, it could be something else). Then ZonedDateTime.of(localDateTime, europeBerlin) takes that date and time of day and claims that it is Europe/Berlin time zone, which is wrong and the reason why you got an incorrect result. You don’t often need the LocalDateTime class and virtually never the no-arg LocalDateTime.now() method.
To get the time in a specific format you need to format the date and time into a string. The LocalDateTime and the ZonedDateTime objects haven’t got any format.
Links
Related questions:
Can’t rid of 'T' in LocalDateTime
String to ZonedDateTime is changing format

Single class to parse any Date Format in Java

I have been parsing dates in the below formats. I maintain an array of these formats and parse every date string in all these formats.
The code I used was -
SimpleDateFormat simpleDateFormat = new SimpleDateFormat(dateFormat);
simpleDateFormat.setTimeZone(timeZone); //timeZone is a java.util.TimeZone object
Date date = simpleDateFormat.parse(dateString);
Now I want to parse yyyy-MM-dd'T'HH:mm:ss.SSSSSSXXX format as well but using SimpleDateFormat the 6 digit microseconds are not considered. So I looked into java.time package.
To parse yyyy-MM-dd'T'HH:mm:ss.SSSSSSXXX formats I will be needing OffsetDateTime class and for other formats, I need ZonedDateTime class. The format will be set in DateTimeFormatter class.
Is there a way to use a single class like SimpleDateFormat to pass all the formats?

Since your Java 8 doesn’t behave as would be reasonably expected, I suggest that a workaround is trying to parse without zone first. If a zone or an offset is parsed from the string, this will be used. If the parsing without zone fails, try with a zone. The following method does that:
private static void parseAndPrint(String formatPattern, String dateTimeString) {
// Try parsing without zone first
DateTimeFormatter formatter = DateTimeFormatter.ofPattern(formatPattern);
Instant parsedInstant;
try {
parsedInstant = formatter.parse(dateTimeString, Instant::from);
} catch (DateTimeParseException dtpe) {
// Try parsing with zone
ZoneId defaultZone = ZoneId.of("Asia/Calcutta");
formatter = formatter.withZone(defaultZone);
parsedInstant = formatter.parse(dateTimeString, Instant::from);
}
System.out.println("Parsed instant: " + parsedInstant);
}
Let’s try it:
parseAndPrint("yyyy-MM-dd'T'HH:mm:ss.SSSSSSXXX", "2018-10-22T02:17:58.717853Z");
parseAndPrint("yyyy-MM-dd'T'HH:mm:ss.SSSSSS", "2018-10-22T02:17:58.717853");
parseAndPrint("EEE MMM d HH:mm:ss zzz yyyy", "Mon Oct 22 02:17:58 CEST 2018");
Output on Java 8 is:
Parsed instant: 2018-10-22T02:17:58.717853Z
Parsed instant: 2018-10-21T20:47:58.717853Z
Parsed instant: 2018-10-22T00:17:58Z
The first example has an offset in the string and the last a time zone abbreviation in the string, and in both cases are these respected: the instant printed has adjusted the time into UTC (since an Instant always prints in UTC, its toString method makes sure). The middle example has got neither offset nor time zone in the string, so uses the default time zone of Asia/Calcutta specified in the method.
That said, parsing a three or four letter time zone abbreviation like CEST is a dangerous and discouraged practice since the abbreviations are often ambiguous. I included the example for demonstration only.
Is there a way to use a single class…?
I have used Instant for all cases, so yes there is a way to use just one class. The limitation is that you do not know afterward whether any time zone or offset was in the string nor what it was. You didn’t know when you were using SimpleDateFormat and Date either, so I figured it was OK?
A bug in Java 8?
The results from your demonstration on REX tester are disappointing and wrong and do not agree with the results I got on Java 11. It seems to me that you have been hit by a bug in Java 8, possibly this one: Parsing with DateTimeFormatter.withZone does not behave as described in javadocs.

Trying to parse a datetime in PDT to a ZonedDateTime representation

How should I parse this datetime value that is in the PDT timezone?
06/24/2017 07:00 AM (PDT)
I want to maintain the timezone so that I can then represent the time in other timezones depending on the website visitors preferences.
I tried using ZonedDateTime but I get a parse error:
java.time.ZonedDateTime.parse("06/24/2017 07:00 AM (PDT)")
The error is:
java.time.format.DateTimeParseException: Text '06/24/2017 07:00 AM (PDT)' could not be parsed at index 0
at java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1949)
at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1851)
at java.time.ZonedDateTime.parse(ZonedDateTime.java:597)
at java.time.ZonedDateTime.parse(ZonedDateTime.java:582) ... 29 elided
Also, do you agree that I should be using a ZonedDateTime?

Since your format is non-standard, you need to specify it to the parser:
ZonedDateTime.parse(
"06/24/2017 07:00 AM (PDT)",
DateTimeFormatter.ofPattern("MM/dd/yyyy HH:mm a (zzz)")
);

The parse method expects a String in a specific format, like 2007-12-03T10:15:30+01:00[Europe/Paris]. As your input is in a different format, you need a DateTimeFormatter.
One detail to notice is that the API uses IANA timezones names (always in the format Continent/City, like America/Sao_Paulo or Europe/Berlin).
Avoid using the 3-letter abbreviations (like CST or PST) because they are ambiguous and not standard.
The API makes some exceptions with specific IDs and provides some defaults for them. For PDT, it defaults to America/Los_Angeles.
Another detail is that in the example below I used lowercase hh in the pattern: the format has AM/PM indication, so I think that hh is the correct pattern, as its value is from 1 to 12 (the common values when there's the AM/PM indicator).
If you use uppercase HH, it allows values from 0 to 23 (and it's not common to use this with AM/PM), and it will throw an exception if the input contains an hour like 07:00 PM.
So the code will be like:
DateTimeFormatter fmt = DateTimeFormatter.ofPattern("MM/dd/yyyy hh:mm a (zzz)");
ZonedDateTime z = ZonedDateTime.parse("06/24/2017 07:00 AM (PDT)", fmt);
System.out.println(z);
The output is:
2017-06-24T07:00-07:00[America/Los_Angeles]
But not all the 3-letter timezone names will be recognized by the API and will throw an exception.
Anyway, there are other timezones that also are in PDT (like America/Vancouver) - you can get a list of all by calling ZoneId.getAvailableZoneIds(). If you want to use a different timezone as the default, you can create a set of preferred zones and build a formatter with this set:
Set<ZoneId> preferredZones = new HashSet<>();
// set America/Vancouver as preferred zone
preferredZones.add(ZoneId.of("America/Vancouver"));
DateTimeFormatter fmt = new DateTimeFormatterBuilder()
// pattern
.appendPattern("MM/dd/yyyy hh:mm a (")
// append timezone with set of prefered zones
.appendZoneText(TextStyle.SHORT, preferredZones)
// finish the pattern
.appendPattern(")")
// create formatter
.toFormatter();
System.out.println(ZonedDateTime.parse("06/24/2017 07:00 AM (PDT)", fmt));
The API will use the preferred zones set (in this case, America/Vancouver) instead of the default (America/Los_Angeles). The output will be:
2017-06-24T07:00-07:00[America/Vancouver]
It's not clear where the input String's come from. If you can't control their format, then you have no choice: they need to be parsed this way. Then you can convert it to another timezone using the withZoneSameInstant method:
// parse the input string
ZonedDateTime z = ZonedDateTime.parse("06/24/2017 07:00 AM (PDT)", fmt);
// convert to another timezone
ZonedDateTime other = z.withZoneSameInstant(ZoneId.of("America/Sao_Paulo")); // 2017-06-24T11:00-03:00[America/Sao_Paulo]
The value of other will be 2017-06-24T11:00-03:00[America/Sao_Paulo].
But if you can control the output, it's always better (IMO) to internally work with UTC (java.time.Instant), and convert to some timezone only when displaying to users:
// convert ZonedDateTime to instant
ZonedDateTime z = // parse input
// convert to UTC (Instant is always in UTC)
Instant instant = z.toInstant();
// internally work with instant (as it's always in UTC)
// convert instant to some timezone only when necessary (like displaying to users)
ZonedDateTime converted = instant.atZone(ZoneId.of("Europe/London"));

The error you get is well covered in the other answers already.
Also, do you agree that I should be using a ZonedDateTime?
Yes and no. Your string should definitely be parsed into a ZonedDateTime. I recommend you convert it to an Instant and store this. Then when you need to present it to a user according to his/her time zone preference, you may either convert the Instant to a ZonedDateTime again or just format it using a DateTimeFormatter with the desired default time zone.
Why do it this way? First, common practice is to store Instants. Some prefer to store just milliseconds since the epoch, I think this some (often misunderstood) performance measure. Certainly such milliseconds I quite unreadable while Instants can be deciphered on eye-sight, at least roughly. The only other alternative I respect is when you know for certain that your application will never need to be concerned with a time zone (does this ever happen?), then sometimes LocalDateTime is used for storage.
If I understand your situation correctly, you need to store the point in time for display into multiple time zones. You don’t need to store the time zone in which the time was originally entered (like PDT, except PDT is not really a full time zone). Instant is time zone neutral, which is one reason I prefer it over storing the time in some time zone, as ZonedDateTime would. Also an Instant is simpler conceptually, and my guess is that it is also simpler implementation-wise.
There are a couple of much better answers here: Best practices with saving datetime & timezone info in database when data is dependant on datetime.