Develop Reference

Date in string to LocalDateTime conversion in java

DateTimes in different formats is always a problem for me. I have a date with the datatype string like "2021-07-25"
I want to convert this date to the datatype LocalDateTime in the format 2021-07-25T00:00:00.000-05:00. I have the get and set property like below
private LocalDateTime relationshipStatusDate;
public LocalDateTime getRelationshipStatusDate() {
return relationshipStatusDate;
}
public void setRelationshipStatusDate(LocalDateTime relationshipStatusDate) {
this.relationshipStatusDate = relationshipStatusDate;
}
public void setRelationshipStatusDate(String time) {
if (time != null) {
try {
long epochTime = Long.parseLong(time);
this.relationshipStatusDate = LocalDateTime.ofInstant(Instant.ofEpochMilli(epochTime), ZoneOffset.UTC);
} catch (NumberFormatException e){
this.relationshipStatusDate = LocalDateTime.parse(time, DateTimeFormatter.ISO_DATE_TIME);
}
}
}
and I am trying to format like below and its failing with an error "Unknown pattern letter T"
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-ddT00:00:00.000-05:00");
LocalDateTime dateTime = LocalDateTime.parse(statusDate, formatter);

Your format won't be parsable as it doesn't support default values like T00:00:00.000-05:00. You could escape literals e.g. use 'T00:00...' but that would just make the parser ignore them.
Instead, if all you get is a date then only parse a date and add the default time after that, e.g. like this:
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd")
LocalDate date = LocalDate.parse(statusDate, formatter );
LocalDateTime dateTime = date.atStartOfDay(); //"relative" representation as the absolute instant would require adding a timezone
ZonedDateTime zonedDT = date.atSTartOfDay(ZoneOffset.UTC); //"absolute" representation of instant
I want to convert this date to the datatype LocalDateTime in the format 2021-07-25T00:00:00.000-05:00.
Note the potential misconception here: LocalDateTime does NOT have a format. It represents a date and time (from a local point of reference - not in absolute terms as the timezone is missing) and provides access to individual fields such as day of month, day of week etc. but it is not formatted. Formatting is applied when you convert that date object to a string.

tl;dr
LocalDate // Represent a date-only value, without a time-of-day and without a time zone or offset-from-UTC.
.parse( "2021-07-25" ) // Parse a string in standard ISO 8601 format to instantiate a `LocalDate` object.
.atStartOfDay( // Determine the first moment of the day on that date in that zone. NB: The day does *not* always begin at 00:00, so never assume that time.
ZoneId.of( "America/Bogota" ) // Real time zones have a name in Continent/Region format. Never use 2-4 letter pseudo-zones such as `CST` or `IST`.
) // Returns a `ZonedDateTime` object, a moment in the context of a time zone.
.toOffsetDateTime() // Strips away the time zone information, leaving only a date with time-of-day in a particular offset. Returns an `OffsetDateTime` object.
.toString() // Generate text in standard ISO 8601 format.
2021-07-25T00:00-05:00
Details
LocalDateTime is the wrong class
You said:
datatype LocalDateTime in the format 2021-07-25T00:00:00.000-05:00
That is a contradiction. The -05:00 at the end of your string is an offset-from-UTC. A LocalDateTime object has no offset.
You seem to misunderstand the purpose of LocalDateTime. That class does not represent a moment as seen through the wall-clock time with an offset-from-UTC used by the people of a particular region. For that purpose, use OffsetDateTime, or preferably, ZonedDateTime.
Use documentation rather than intuition when programming with unfamiliar classes. To quote the Javadoc for LocalDateTime:
A date-time without a time-zone … such as 2007-12-03T10:15:30.
…
This class does not store or represent a time-zone. Instead, it is a description of the date, as used for birthdays, … It cannot represent an instant on the time-line …
Here is my chart to summarize the types. Three classes represent a moment, while LocalDateTime does not.
You said:
I have a date with the datatype string like "2021-07-25"
So use LocalDate to represent that value.
By default, the java.time classes use standard ISO 8601 format when parsing/generating text. So no need to specify a formatting pattern here, as your input complies with that standard.
LocalDate ld = LocalDate.parse( "2021-07-25" ) ;
You said:
I want to convert this date to … the format 2021-07-25T00:00:00.000-05:00
Your example there uses only a mere offset rather than a time zone. I suggest you use a time zone whenever possible.
An offset is simply a number of hours-minutes-seconds, nothing more. A time zone is much more. A time zone is a history of the past, present, and future changes to the offset used by people of a particular region, as decided by their politicians.
ZoneId
So specify your time zone using Continent/Region naming.
ZoneId z = ZoneId.of( "America/Cancun" );
ZonedDateTime
Let java.time determine the first moment of the day on that date as seen in that time zone. Be aware that the day does not always start at 00:00. So never hard-code that time-of-day; let java.time do the work here.
ZonedDateTime zdt = ld.atStartOfDay( z ); // Determine the first moment of the day as seen in that zone. Not always 00:00.
Generate text to represent the value inside our ZonedDateTime. The ZonedDateTime#toString method generates text in a format that wisely extends the ISO 8601 format by appending the name of the time zone in square brackets.
String output = zdt.toString();
2021-07-25T00:00-05:00[America/Cancun]
Pull all that code together.
LocalDate ld = LocalDate.parse( "2021-07-25" );
ZoneId z = ZoneId.of( "America/Cancun" );
ZonedDateTime zdt = ld.atStartOfDay( z ); // Determine the first moment of the day as seen in that zone. Not always 00:00.
String output = zdt.toString();
See this code run live at IdeOne.com.
2021-07-25T00:00-05:00[America/Cancun]
OffsetDateTime
If you insist on generating text in your stated format, while omitting the name of the time zone, use OffsetDateTime.
String output = zdt.toOffSetDateTime().toString() ;
All of these topics have been covered many times on Stack Overflow. Search to learn more.

How can i convert the windows timezone to Java Timezone?

I'm getting windows time zone as input, which i want to convert it to UTC time in Java. some windows time zone are not same as Java's.
For example:
Windows time zone = MPST(Malay Peninsula Standard Time)
equivalent Java time zone = SGT (Singapore Standard Time)
My input be like - 13/01/2020 10:46:10 MPST. so, when i'm trying to convert this date format to UTC, i'm getting java.text.ParseException: Unparseable date: "13/01/2020 10:46:10 MPST"
Please, help.
Thanks in advance

Avoid pseudo-codes for time zones
The 2-4 letter pseudo-codes often seen in the media are not actual time zones. Values such as IST, PST, CST, and your MPST are not standardized, and are not even unique!
Use only proper time zone names in the format of Continent/Region. See this possibly-outdated list at Wikipedia.
ZoneId z = ZoneId.of( "Asia/Kuala_Lumpur" ) ;
ZonedDateTime now = ZonedDateTime.now( z ) ;
020-01-15T08:02:26.612494+08:00[Asia/Kuala_Lumpur]
See that code run live at IdeOne.com.
The DateTimeFormatter class will try to guess the real time zone intended by the use of a 2-4 letter pseudo-zone. For example:
String input = "13/01/2020 10:46:10 PST" ;
DateTimeFormatter f = DateTimeFormatter.ofPattern( "dd/MM/uuuu HH:mm:ss zz") ;
ZonedDateTime zdt = ZonedDateTime.parse( input , f ) ;
System.out.println( "zdt.toString(): " + zdt ) ;
zdt.toString(): 2020-01-13T10:46:10-08:00[America/Los_Angeles]
But guessing MPST fails with a runtime error.
ISO 8601
In any such case as either PST or MPST, you really should go back to the source of the data. Educate those people about the ISO 8601 standard designed for the purpose of exchanging date-time values as text.
By the way, the toString method of the ZonedDateTime class seen above extends the ISO 8601 standard format by wisely appending the name of the time zone in square brackets.

Does a 'z' in a datetime String have different outputs in different locales?

Not long ago, I provided an answer to a question about how to extract the time zone from a ZonedDateTime parsed from a String.
It worked in general, but there were different outputs of the same code on OP's system an my one, which somehow doesn't let me go anymore.
The related question asked how to get a ZoneId from a ZonedDateTime and I provided a way. Admittedly, it is not the accepted answer, but still seemed worth an upvote from someone.
The special thing about my answer is concerning the 'z' in the pattern used to parse the time String. There is a time zone name in that String representing the zone "Australia/Adelaide" by "... ACST" (Australian Central Standard Time).
When I parse it on my system and print/format the ZonedDateTime using the DateTimeFormatter.ISO_ZONED_DATE_TIME, it prints the time in "America/Manaus" and having extracted the ZoneId, it is still that one from South America. OP stated in a comment below my answer, that on his system, at least one of the output lines shows the desired/correct ZoneId.
How is that possible? Does the system default locale have any influence on parsing the 'z' in datetime Strings?
This is the code from my answer in the question plus an output of my ZoneId.systemDefault():
public static void main(String args[]) throws Exception {
String time = "2 Jun 2019 03:51:17 PM ACST";
String pattern = "d MMM yyyy hh:mm:ss a z"; // z detects the time zone (ACST here)
DateTimeFormatter formatter = DateTimeFormatter.ofPattern(pattern);
// parse a time object using the formatter and the time String
ZonedDateTime zdt = ZonedDateTime.parse(time, formatter);
// print it using a standard formatter
System.out.println(zdt.format(DateTimeFormatter.ISO_ZONED_DATE_TIME));
// extract the zone id
ZoneId zoneId = zdt.getZone();
ZoneId sysDefault = ZoneId.systemDefault();
// print the zone id
System.out.println("Time zone of parsed String is " + zoneId);
System.out.println("System default time zone is " + sysDefault);
// retrieve the instant seconds
Instant instant = zdt.toInstant();
// print the epoch seconds of another time zone
System.out.println("Epoch seconds in Australia/Adelaide are "
+ instant.atZone(ZoneId.of("Australia/Adelaide")).toEpochSecond());
}
and its output is this:
2019-06-02T15:51:17-04:00[America/Manaus]
Time zone of parsed String is America/Manaus
System default time zone is Europe/Berlin
Epoch seconds in Australia/Adelaide are 1559505077
Can anyone point me to a mistake I have made or confirm and explain the influence of different system default ZoneIds on parsing a String to a ZonedDateTime?

I too have experienced ambiguous time zone abbreviations being parsed differently on different JVMs (also when providing a locale, so that is not the only issue). I don't think the exact behaviour is documented. In some cases the JVMs default time zone was chosen, I don't know if it will always be when it matches, though.
You can control the choice of time zone in ambiguous cases through the overloaded DateTimeFormatterBuilder.appendZoneText(TextStyle, Set<ZoneId>) method.
An example where locale makes a difference: Europe/Berlin and many other European time zones will be formatted into Central European Time or CET in many locales. In a German locale they instead become Mitteleuropäische Zeit or MET.

The Answer by Ole V.V. is correct.
ISO 8601
Furthermore, strings such as "2 Jun 2019 03:51:17 PM ACST" should not be parsed. Such formats should never be used to exchange date-time values. Such strings should be used only for presentation to the human user, not for data-exchange.
Would you try the exchange the monetary amount of USD 23.67 as twenty three dollars and sixty-seven cents in United States dollars or as vingt-trois dollars et soixante-sept cents en dollars des États-Unis?
To exchange date-time values via text, always use the standard ISO 8601 formats. The sensible formats are designed to be unambiguous, easy to parse by machine, and easy to read by humans across cultures.
If using a time zone, use the ZonedDateTime::toString method to generate text. This method wisely extends the ISO 8601 format to append the name of the time zone in square brackets.
ZoneId z = ZoneId.of( "Australia/Adelaide" ) ;
String output = ZonedDateTime.now( z ).toString() ;
2020-02-10T06:30:57.756491+10:30[Australia/Adelaide]
Run that code live at IdeOne.com.
Parsing.
ZonedDateTime zdt = ZonedDateTime.parse( output ) ;
Even better, use UTC values when the time zone is not directly relevant. To capture and communicate the current moment in UTC, use Instant.
Again, call toString & parse to generate and parse text in standard ISO 8601 format. The Z on the end means UTC, an offset of zero hours-minutes-seconds, and is pronounced “Zulu”.
String output = Instant.now().toString() ;
2020-02-09T20:07:42.718473Z

Date conversion from yyyy-MM-dd HH:mm:ss to ISO date yyyy-MM-dd'T'HH:mm:ssXXX format issue

I'm trying to convert date format from yyyy-MM-dd HH:mm:ss to ISO date format yyyy-MM-dd'T'HH:mm:ss+5:30, and tested it by below code and it was working fine when ran on eclipse and causing an issue on deployment to server through jar.
The issue is date(input: 2016-01-08 10:22:03) is converted to something like, 2016-01-08T10:22:03Z instead of 2016-01-08T10:22:03+5:30.
Note: I'm using Java 8.
Following is the code used to convert the date,
SimpleDateFormat outputDate = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssXXX");
SimpleDateFormat inputDate = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
String FinalDate = outputDate.format(inputDate.parse(pickupDate));
System.out.println(finalDate);
Other weird experience is, on some machine the issue is not reproducible and in some machine the issue exists. Is it something machine or JVM dependent? Please help.
Thank you in advance.

As by documentation of SimpleDateFormat:
For formatting, if the offset value from GMT is 0, "Z" is produced. If
the number of pattern letters is 1, any fraction of an hour is
ignored. For example, if the pattern is "X" and the time zone is
"GMT+05:30", "+05" is produced.
So my guess is probably to check the timezone of your server. Since it thinks that the timezone of the entered date is GMT 0.

java.time
If using Java 8 or later, you should be using the java.time classes rather than those notoriously troublesome date-time classes, java.util.Date/.Calendar.
ISO 8601
Your input strings are close to the standard ISO 8601 format. The java.time classes use these standard formats by default when parsing and generating textual representations of date-time values. No need to define a coded parsing pattern for such standard inputs.
To fully comply with ISO 8601, replace that SPACE in the middle with a T.
String inputStandardized = "2016-01-08 10:22:03".replace( " " , "T" );
Parsing Without Time Zone Or Offset
This string has no offset-from-UTC or time zone, so we first create a LocalDateTime.
LocalDateTime localDateTime = LocalDateTime.parse( inputStandardized );
Such objects are a vague idea of a date-time but are not really on the timeline. To define a real moment on the timeline we must apply a time zone.
ZoneId zoneId = ZoneId.of( "Asia/Kolkata" );
ZonedDateTime zdt = localDateTime.atZone( zoneId );
Apply Time Zone
Note that that particular date + time may not be valid in the specified time zone; java.time adjusts as necessary. Be sure to read the documentation to understand the adjustment behavior.
Formatted Strings
The toString method on ZonedDateTime by default generates a String in the format you desire, except extended to append the name of the time zone in square brackets.
String output = zdt.toString();
2016-01-08T10:22:03+05:30[Asia/Kolkata]
This extension to include time zone name makes much sense. A time zone is not just an offset-from-UTC, it also includes the present and historical rules for handling anomalies such as Daylight Saving Time (DST).
If you really do not want that appended time zone name, against my advice, you can use an alternate formatting pattern, ISO_OFFSET_DATE_TIME, already defined in java.time as a constant.
DateTimeFormatter formatter = DateTimeFormatter.ISO_OFFSET_DATE_TIME ;
String output = zdt.format( formatter );
2016-01-08T10:22:03+05:30
Pad Hour Of Offset
By the way, you can avoid problems by always including a leading padding zero in the hours of your offset-from-UTC. So use +05:30 rather than +5:30 as seen in the Question.

How to convert a date and time in one time zone to other in java

I am trying to convert GMT+2 time to GMT-4 time.But i am getting unexpected results.Help me on how to achieve that conversion of one time zone time to other time zone time.
originTime = "2015-08-15T10:25:00";
SimpleDateFormat converter = new SimpleDateFormat("yyyy-MM-dd hh:mm");
converter.setTimeZone(TimeZone.getTimeZone("GMT-4"));
GregorianCalendar oc = originTime.toGregorianCalendar();
String OriginStart=converter.format(oc.getTime());
The above code has to give the originStart time lesser than the given time If it is GMT-4.
But Im getting OriginStart time greater than the given time.

Assuming the timzone strings are valid (as i haven't tried it) try something like
String originTime = "2015-08-15 10:25";
SimpleDateFormat converter = new SimpleDateFormat("yyyy-MM-dd hh:mm");
converter.setTimeZone(TimeZone.getTimeZone("GMT+10"));
Date date = converter.parse (originTime);
converter.setTimeZone(TimeZone.getTimeZone("GMT-4"));
String OriginStart=converter.format(date);

Padding Zero
Generally, use a padding zero for offset hours. But this is not a problem in your specific code. At least not according to the doc for TimeZone class which explicitly accepts single digit.
The ISO 8601 standard requires offset hours to have a padding zero. So use -04 rather than -4.
By the way, the original release of java.time had a bug where it failed to parse offsets values of just hour without menu. So in that case, use -04:00 rather than -04.
Named Time Zone
A time zone is more that just an offset from UTC (GMT). A time zone includes rules about Daylight Savings Time (DST) and other anomalies, past, present, and future. So use a specific time zone name if you have one in mind.
An example of a +02:00 time zone name would be Africa/Bujumbura. An example of -04:00, America/Martinique.
Avoid java.util.Date
The java.util.Date/.Calendar and SimpleDateFormat classes are notoriously troublesome and confusing. Perhaps the worst of the bundled Java libraries. Avoid them.
Instead use either Joda-Time or the new java.time package built into Java 8 (inspired by Joda-Time).
ISO 8601
The ISO 8601 standard defines sensible unambiguous string formats for date-time values. Your input string format complies with this wise standard.
Both Joda-Time and java.time parse and generate strings in ISO 8601 format by default. So no need to specify a formatter.
Example
Example code written in Joda-Time 2.7.
Define the input, formatted in ISO 8601 without any offset from UTC.
String input = "2015-08-15T10:25:00";
Specify time zones if input and output.
DateTimeZone zoneInput = DateTimeZone.forOffsetHours( 2 );
// DateTimeZone zoneInput = DateTimeZone.forID( "Africa/Bujumbura" ); // Preferably the specific time zone name.
DateTimeZone zoneTarget = DateTimeZone.forOffsetHours( -4 );
// DateTimeZone zoneTarget = DateTimeZone.forID( "America/Martinique" ); // Preferably the specific time zone name.
Parse the string, while assigning a time zone. Then adjust the time zone.
DateTime dateTimeOriginal = new DateTime( input , zoneInput );
DateTime dateTimeTarget = dateTimeOriginal.withZone( zoneTarget );
Dump to console.
System.out.println( "zoneInput / zoneTarget : " + zoneInput + " / " + zoneTarget );
System.out.println( "dateTimeOriginal : " + dateTimeOriginal );
System.out.println( "dateTimeTarget : " + dateTimeTarget );
When run.
zoneInput / zoneTarget : +02:00 / -04:00
dateTimeOriginal : 2015-08-15T10:25:00.000+02:00
dateTimeTarget : 2015-08-15T04:25:00.000-04:00