Develop Reference

SimpleDateFormat parse method works first time, is ignored second time

I have a date time that I am first converting to local time, followed by a conversion to another time zone. The first conversion works with no issue however the second conversion is ignored. What is the issue?
String input = "2020-05-20 01:10:05";
SimpleDateFormat localFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
localFormat.setTimeZone(TimeZone.getTimeZone(ZoneId.systemDefault()));
try {
Date date = localFormat.parse(input);
System.out.println(date); //Wed May 20 01:10:05 PDT 2020 <--- Logs this (Expected)
SimpleDateFormat estFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
estFormat.setTimeZone(TimeZone.getTimeZone("America/New_York"));
String newDate = estFormat.format(date);
System.out.println(newDate); //2020-05-20 04:10:05 <--- Logs this (Expected)
Date dateEst = estFormat.parse(newDate);
System.out.println(dateEst); //Wed May 20 01:10:05 PDT 2020 <--- Logs this (Unexpected) Should be Wed May 20 04:10:05 EST 2020
}catch (Exception e){
e.printStackTrace();
}
It seems like the second estFormat.parse() is ignored when trying to convert to America/New_York time zone.

java.time
I warmly recommend that you use java.time, the modern Java date and time API, for your date and time work. Once you get used to the slightly different mindset, you will likely also find the resulting code clearer and more natural to read. Let’s first define the constant stuff as constants:
private static final DateTimeFormatter FORMATTER
= DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss", Locale.ROOT);
private static final ZoneId FROM_ZONE = ZoneId.of("America/Los_Angeles");
private static final ZoneId TO_ZONE = ZoneId.of("America/New_York");
With these we can do our work:
String input = "2020-05-20 01:10:05";
ZonedDateTime fromDateTime
= LocalDateTime.parse(input, FORMATTER).atZone(FROM_ZONE);
System.out.println("From: " + fromDateTime);
ZonedDateTime toDateTime = fromDateTime.withZoneSameInstant(TO_ZONE);
System.out.println("To: " + toDateTime);
String formatted = toDateTime.format(FORMATTER);
System.out.println("Formatted: " + formatted);
Output is:
From: 2020-05-20T01:10:05-07:00[America/Los_Angeles]
To: 2020-05-20T04:10:05-04:00[America/New_York]
Formatted: 2020-05-20 04:10:05
Edit:
How would I get it to have EST 2020 at the end?
A good option for most purposes is to use a localized formatter:
private static final DateTimeFormatter TARGET_FORMATTER
= DateTimeFormatter.ofLocalizedDateTime(FormatStyle.LONG)
.withLocale(Locale.US);
Like this:
String formatted = toDateTime.format(TARGET_FORMATTER);
Formatted: May 20, 2020 at 4:10:05 AM EDT
A detail, we didn’t get EST at the end because New York and most of the East coast of Northern America uses summer time (DST) and hence is on Eastern Daylight time, EDT, in May.
What went wrong?
It seems that you were expecting your Date object to carry the time zone of the formatter that parsed it, America/New_York. An old-fashioned Date object cannot do that. It’s just a dumb point in time without any time zone or other additional information. What confuses many is that its toString method uses the default time zone of the JVM to render the string returned, thus giving the false impression of a time zone being present. In contrast the modern ZonedDateTime, as the name says, does hold a time zone.
Link
Oracle tutorial: Date Time explaining how to use java.time.

First, don't use Date unless you're maintaining legacy code.
Second, SimpleDateFormat parsed the date correctly. You're not using estFormat to format the date as you did in the previous (correct) example. Try:
System.out.println(estFormat.format(dateEst));
This is a good overview of the different types of date-related entities in Java and is worthwhile reading. Here's an excerpt you may find useful:
The java.util.Date has no concept of time zone, and only represents the number of seconds passed since the Unix epoch time – 1970-01-01T00:00:00Z. But, if you print the Date object directly, the Date object will be always printed with the default system time zone.

I had noticed one thing the type of the first variable is String and the type of the Second variable is Date. So probably type conversion is creating a problem here. There is nothing like ignoring a second time.

Not able to understand "YYYY-MM-DDTHH:MM:SS" date format

I am trying to parse following date time string
2018-01-30T23:59:59.000
I am not able to understand which standard format it is like UTC or ISO_8601
while parsing in the following manner:
SimpleDateFormat sdf = new SimpleDateFormat("YYYY-MM-DD'T'HH:MM:SS:MS");
Date date = null;
try {
date = sdf.parse("2018-01-30T23:59:59.000");
} catch (ParseException e) {
e.printStackTrace();
}
But It is throwing following exception:
java.text.ParseException: Unparseable date: "2018-01-30T23:59:59.000"
Any help is appreciated.

See the doc of SimpleDateFormat and try this:
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSS");

LocalDateTime dateTime = LocalDateTime.parse("2018-01-30T23:59:59.000");
System.out.println(dateTime);
This prints:
2018-01-30T23:59:59
Your string is in ISO 8601 format. UTC or Coordinated Universal Time is not a format, it is a standard time used to define the time the rest of use in our respective time zones.
The date-time classes you were using, SimpleDateFormat and Date, are long outdated and the former in particular notoriously troublesome. I recommend that you instead use java.time, the modern Java date and time API. It is so much nicer to work with.
A LocalDateTime is a date with time of day and without time zone or offset from UTC. Its one-argument parse method parses ISO 8601, which is why no explicit formatter is needed.
What went wrong in your code
Your format pattern string has a number of issues to it. Which is one reason why you should appreciate the above solution without any explicit formatter. The first thing that goes wrong is: Your format pattern string has a colon, :, between seconds and milliseconds, whereas your date-time string has a dot, .. This is why you get the exception.
However, fixing this, your code yields the following Date:
Sun Dec 31 23:00:00 CET 2017
It’s one month off from the expected, and the minutes and seconds are missing. Because:
Uppercase YYYY is for week-based year and only useful with a week number. You need lowercase yyyy for year.
Uppercase DD is for day of year. You need lowercase dd for day of month.
You correctly used uppercase MM for month. Trying the same again for minutes won’t work. Maybe you can guess by now: it’s lowercase mm.
Not surprising you need lowercase ss for seconds.
UsingMS for milliseconds is interesting. SimpleDateFormat takes it as M for month (which we’ve already had twice before) and uppercase S for millisecond. Instead you needed uppercase SSS for the three digits of milliseconds.
Links
Oracle tutorial: Date Time explaining how to use java.time.
Wikipedia article: ISO 8601
Wikipedia article: Coordinated Universal Time on UTC

You need to escape the literal T:
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:SS");
See This SO Answer for more examples
Update: Your string is in the format
yyyy-MM-dd'T'HH:mm:ss.SSS
but you are trying to parse it with a completely uppercase format string.
This does not do what you want it to do and you should read the documentation on SimpleDateFormat and the format string placeholders

Parsing string to date: Illegal pattern character 'T'.

I need to parse a string to date in java. My string has the following format:
2014-09-17T12:00:44.0000000Z
but java throws the following exception when trying to parse such format... java.lang.IllegalArgumentException: Illegal pattern character 'T'.
Any ideas on how to parse that?
Thank you!

Given your input of 2014-09-17T12:00:44.0000000Z, it is not sufficient to escape the letter T only. You also have to handle the trailing Z. But be aware, this Z is NOT a literal, but has the meaning of UTC+00:00 timezone offset according to ISO-8601-standard. So escaping Z is NOT correct.
SimpleDateFormat handles this special char Z by pattern symbol X. So the final solution looks like:
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSSSSSX");
Date d = sdf.parse("2014-09-17T12:00:44.0000000Z");
System.out.println(d); // output: Wed Sep 17 14:00:44 CEST 2014
Note that the different clock time is right for timezone CEST (toString() uses system timezone), and that the result is equivalent to UTC-time 12:00:44. Furthermore, I had to insert seven symbols S in order to correctly process your input which pretends to have precision down to 100ns (although Java pre 8 can only process milliseconds).

You have to escape the 'T' character:
SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'", Locale.US);
format.setTimeZone(TimeZone.getTimeZone("UTC"));
Date parse = format.parse("2014-09-17T12:00:44.0000000Z");
Using Answer to: What is this date format? 2011-08-12T20:17:46.384Z

java.time
It is time for the modern answer: always use java.time, the modern Java date and time API, for your date and time work. When this question was asked, java.time had been out with Java 8 for 7 months. Today (2020) no one should use the SimpleDateFormat class that appears to have been the trouble in the question. It is notoriously troublesome and long outdated.
Using java.time we need no explicit formatter:
String str = "2014-09-17T12:00:44.0000000Z";
Instant i = Instant.parse(str);
System.out.println("As Instant: " + i);
Output is:
As Instant: 2014-09-17T12:00:44Z
Your format is ISO 8601 (link at the bottom). The classes of java.time generally parse ISO 8601 as their default and print ISO 8601 back from their toString methods. In ISO 8601 the fraction of second is optional.
If you need a Date object for a legacy API not yet upgraded to java.time:
Date oldfashionedDate = Date.from(i);
System.out.println("As old-fashioned Date: " + oldfashionedDate);
Output in my time zone:
As old-fashioned Date: Wed Sep 17 14:00:44 CEST 2014
Output will vary by time zone because Date.toString() confusingly takes the JVM’s default time zone and uses it for rendering the string.
What went wrong for you?
You haven’t shown us your code, but we can already tell that a couple of things are wrong:
SimpleDateFormat cannot parse a string with 7 fractional digits on the seconds correctly. It supports only milliseconds, exactly three decimals.
In your format pattern string you need to escape the literal T by enclosing it in single quotes, 'T', or SimpleDateFormat will understand it as a pattern letter, and there is no format pattern letter T. This is what your exception message meant.
Links
Oracle tutorial: Date Time explaining how to use java.time.
Wikipedia article: ISO 8601.
Related question: Date object SimpleDateFormat not parsing timestamp string correctly in Java (Android) environment about parsing more than three decimals on the seconds.
Related question: ISO 8601 String to Date/Time object in Android.

Try this.
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Date;
public class DateClass {
public static void main(String[] args) throws ParseException {
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'");
Date d = sdf.parse("2014-09-17T12:00:44.0000000Z");
System.out.println(d); //output Wed Sep 17 12:00:44 IST 2014
}
}

How to Convert JavaScript Date to Date in Java?

I need to convert JsDate to java.util.Date. I searched but I couldn't find anything. So could you help me with this problem?
Edit: I do this conversion process on GWT screen. I have Datepicker on screen and it gives me JsDate value when I use it's getValue() method. So I'm supposed to put this value into the property of an object which has Date type.
ObjectName.setDate(PickerName.getValue());
I hope my edit will be more clear.
Edit2:
This line is the solution of my problem:
myObject.setDate(new Date((long) myPicker.getValue().getTime()));

The best way of dates conversion is using time in milliseconds, UTC. Both JS Date object and java.util.Date class support conversion to milliseconds (getTime()) and instantiating from milliseconds (using constructor).

You can create a java.util.Date object from the 'time since epoch' value of the JS Date
javascript
var d = new Date().getTime();
java
// get value from client (ajax, form, etc), and construct in Date object
long valueFromClient = ...
Date date = new Date(valueFromClient);
String formatted = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(date);

If people like me are forced to parse a JS-formatted date string (as the result of (new Date()).toString() in JavaScript), here is the SimpleDateFormat spec I used:
DateFormat jsfmt = new SimpleDateFormat("EE MMM d y H:m:s 'GMT'Z (zz)");
If you have control of the producer of the dates, I concur that using timestamps or at least .toUTCString() is definitely more robust.

You may want this:
java:
String jsDate="2013-3-22 10:13:00";
Date javaDate=new SimpleDateFormat("yy-MM-dd HH:mm:ss").parse(jsDate);
System.out.println(javaDate);

ISO 8601 and java.time
ISO 8601 is the international standard for date and time including date and time formats. About any programming language has support for it, including both JavaScript and Java.
In JavaScript produce a string in ISO 8601 format using Date.toISOString(). We don’t need any formatter.
var d = new Date();
var n = d.toISOString();
console.log(n);
The result is somewhat human readable as long as you remember that it’s in UTC, denoted by the trailing Z.
In Java parse the string using Instant.parse(). We don’t need to specify any formatter here either.
String stringFromJavaScript = "2021-07-12T05:54:03.365Z";
Instant inst = Instant.parse(stringFromJavaScript);
System.out.println(inst);
Output:
2021-07-12T05:54:03.365Z
The question asked for a java.util.Date for the result from a date picker. We should avoid using java.util.Date for this both because despite the name a Date does not represent a date and because the Date class is poorly designed and long outdated. For a date without time of day a LocalDate is appropriate:
LocalDate date = inst.atZone(ZoneId.systemDefault()).toLocalDate();
System.out.println(date);
In my time zone the output was:
2021-07-12
The conversion is time zone dependent and will only be correct if the default time zone of the JVM (or which time zone you pass to atZone()) is the same as used by the date picker.
If you do need a Date for a legacy API not yet upgraded to java.time:
Date oldfashionedDate = Date.from(inst);
System.out.println(oldfashionedDate);
Mon Jul 12 07:54:03 CEST 2021
Links
Wikipedia article: ISO 8601
Oracle tutorial: Date Time explaining how to use java.time.

I would suggest using the DateFormat parse method (doc can be found here). It can parse a string representation of a date and return a java.util.Date.

JS Date --
new Date()
Wed Aug 14 2019 14:54:38 GMT+0530 (India Standard Time)
Java Date --
new Date().toISOString()
"2019-08-14T09:25:50.136Z"

Why does "12:00" converted to UTC become "11:00"?

I thought 2011-10-23 12:00:00 would remain the same as UTC and that the Converted date would be 2011-10-23 17:00:00.
DateFormat formatter = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
Date dt = formatter.parse("2011-10-23 12:00:00");
LocalDateTime ldt = new DateTime(dt).withZone(DateTimeZone.UTC).toLocalDateTime();
LOGGER.warn("Original date: " + ldt.toDateTime().toDate().toString());
DateTime cvtldt = ldt.toDateTime(DateTimeZone.forID("-05:00"));
LOGGER.warn("Converted date: " + cvtldt.toLocalDateTime().toDateTime().toDate().toString());
I don't understand why the output is minus one hour?
Original date: Sun Oct 23 11:00:00 BST 2011
Converted date: Sun Oct 23 11:00:00 BST 2011

You're using Date.toString() which always uses the local time zone. See how your string contains "BST"?
Ideally, stick to just Joda Time for as much of the time as you can:
Parse with the Joda Time formatters
Don't convert back to Date unless you need to
Don't use Date.toString() if you can possibly avoid it; you have no control over its format.
It's not clear what you're really trying to achieve, but you almost certainly don't want to do this many conversions. For example, you're calling toLocalDateTime() followed by toDateTime() again - which means it's using the system default time zone, after you'd carefully specified UTC in the previous conversion...
Your code contains the following conversions (in this order):
String to Date
Date to DateTime
DateTime to DateTime in UTC
DateTime to LocalDateTime (*)
LocalDateTime to DateTime
DateTime to Date
Date to String
(From the results at *) LocalDateTime to DateTime
DateTime to LocalDateTime
LocalDateTime to DateTime
DateTime to Date
Date to String
What do you think the chances of all those conversions being both necessary and correctly specified are? ;)

Original has changed because conversion to the UTC is done with respect to HOST time zone, so it should change.
Converted had changed, in fact it's the problem of accessing method.
You are getting base time and the modifier is stored in other field.
Try going into debugging mode and you will see that after conversion cvtldt
has toString with modifier.
Regards,
Grzesiek