We Keep Coding

SimpleDateFormat.parse() converts DTstring to local time. Can be converted to source's time?

I have followed this SO answer for datetime conversion of 8601.
I will cite an example straight from w3 :
1994-11-05T08:15:30-05:00 corresponds to November 5, 1994, 8:15:30 am, US Eastern Standard Time.
1994-11-05T13:15:30Z corresponds to the same instant.
And this is what I run in android
SimpleDateFormat sdfSource = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZZZZZ");
dateTime = sdfSource.parse("2014-03-06T11:30:00-05:00");
System.out.println(dateTime); //Thu Mar 06 18:30:00 EET 2014
Obviously .parse()'s output is the local aware datetime. There has been a conversion from EST(-05:00) to EET (+02:00) since now I am in this timezone. However I do not want this auto-convertion.
Is there a way to parse a datetime string inyyyy-MM-dd'T'HH:mm:ssZZZZZ format and display THAT timezone's datetime? Preferable output:
Thu Mar 06 11:30:00 EST 2014
The EST and my location is an example. It can be any other timezones as well.

Internally Date objects are in UTC and that's what they're parsed to.
You cannot retrieve the original timezone from the Date but you can attempt to retrieve it from the original ISO-8601 stamp, and use it when formatting.
When you convert it to a string with toString(), it uses your local settings to format the date. If you want a specific representation, use a formatter to format the output, e.g.
int rawTimeZoneOffsetMillis = ...; // retrieve from ISO-8601 stamp and convert to milliseconds
TimeZone tz = new SimpleTimeZone(rawTimeZoneOffsetMillis, "name");
DateFormat outputFormat = DateFormat.getDateTimeInstance();
outputFormat.setTimeZone(tz);
System.out.println(df.format(dateTime));
ISO-8601 timestamps are not completely parseable with SimpleDateFormat. This answer has some code to work around some of the limitations.

Use sdfSource.setTimeZone() method
SimpleDateFormat sdfSource = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZZZZZ");
sdfSource.setTimeZone(TimeZone.getTimeZone("EST")); //give the timezone you want
dateTime = sdfSource.parse("2014-03-06T11:30:00-05:00");
System.out.println(dateTime); //Thu Mar 06 18:30:00 EET 2014
This should do fine.

Although you should not be worried while parsing the date as it is parsed to correct value can be displayed in any format or timezone you want.
SimpleDateFormat sdfSource = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZZZZZ");
sdfSource.setTimeZone( TimeZone.getTimeZone( "EST" ) );
dateTime = sdfSource.parse("2014-03-06T11:30:00-05:00");
System.out.println(sdfSource.format(dateTime)); //Thu Mar 06 18:30:00 EET 2014

how to check different date formats in java

I am getting different date formats below dd-MM-yyyy,dd/MM/yyyy,yyyy-MM-dd,yyyy/MM/dd
SimpleDateFormat sm1 = new SimpleDateFormat("dd-MM-yyyy");
String date = "01-12-2013";
System.out.println("Date 1 is "+sm1.parse(date));
date = "2013-12-01";
System.out.println("Date 1 is "+sm1.parse(date));
the same simple date format gives the below result eventhough date format is wrong(ie:-2013-12-01).Below the results.
Date 1 is Sun Dec 01 00:00:00 IST 2013
Date 1 is Sun Jun 05 00:00:00 IST 7

You need to setLenient(false) to make parse() method throw ParseException for unparsable case

I have tried Jigar Joshi's answer.
==========================code=======================================
SimpleDateFormat sm1 = new SimpleDateFormat("dd-MM-yyyy");
sm1.setLenient(false);
String date = "01-12-2013";
System.out.println("Date 1 is "+sm1.parse(date));
date = "2013-12-01";
System.out.println("Date 1 is "+sm1.parse(date));
=========================Result========================================
Date 1 is Sun Dec 01 00:00:00 CST 2013
Exception in thread "main" java.text.ParseException: Unparseable date: "2013-12-01"
at java.text.DateFormat.parse(DateFormat.java:337)
at workflow.Test.main(Test.java:14)

Your date format is dd-MM-yyyy. That means the parser is expecting some day, month, and year format.
From the SimpleDateFormat documentation: the number of pattern letters in a Number type formatter is the minimum. So, while 2013 wouldn't make sense in our mind, it fits within the formatter's bounds.
You have provided 2013-12-01 as to fit into that format. What it appears the formatter is doing is providing December 1 (insert timezone here), and then adding 2,013 days to it.
That turns out to be June 6, 7 AD. There's some wiggle room for your timezone (I'm not sure which of the five timezones IST represents is actually yours).
So, believe it or not...the formatter is correct. Be very careful as to what kind of format you specify or allow in your dates!
If you don't want that parsed, then specify setLenient(false) on your instance of sm1.

Calendar.getTime() not returning UTC date if TimeZone is defined

I have done this for my Calendar instance to return Date in UTC timezone:
SimpleDateFormat formatter = new SimpleDateFormat("dd-MM-yyyy HH:mm:SS Z");
TimeZone tz = TimeZoneUtil.getTimeZone(StringPool.UTC);
formatter.setTimeZone(tz);
Date dtStart = null;
Date dtEnd = null;
try{
dtStart = formatter.parse(formatter.format(startDate.getTime()));
dtEnd = formatter.parse(formatter.format(endDate.getTime()));
}catch (Exception e) {
e.getStackTrace();
}
It works fine till I format calendar timestamp to return a string date with required timezone but when I parse that string date to Date date, it again picks up local timezone?
I need to store Date object in UTC timezone.
Any help will be highly appreciated!

You can use this:
Date localTime = new Date();
//creating DateFormat for converting time from local timezone to GMT
DateFormat converter = new SimpleDateFormat("dd/MM/yyyy:HH:mm:ss");
//getting GMT timezone, you can get any timezone e.g. UTC
converter.setTimeZone(TimeZone.getTimeZone("GMT"));
System.out.println("local time : " + localTime);;
System.out.println("time in GMT : " + converter.format(localTime));
It will give:
local time: Fri Jun 21 11:55:00 UTC 2013
time in GMT : 21/06/2013:11:55:00
I hope it will help.
Cheers.

Date object in java will always store the values in the host machine (your system) time zone information.
This is from javadoc :
Although the Date class is intended to reflect coordinated universal time (UTC), it may not do so exactly, depending on the host environment of the Java Virtual Machine.
You should trying using Joda Time which is much advanced.

Instead of setting TimeZone in multiple places, it is a good idea to set timezone using -Duser.timezone=GMT or PST.
And, you can easily test how Java deals with timezone and getTime() ignores timezone with an actual example:
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ"); // print with timezone
TimeZone timeZone = TimeZone.getTimeZone(ZoneId.of("GMT"));
TimeZone.setDefault(timeZone); // set system timezone as GMT
sdf.setTimeZone(timeZone); // formatter also has a timezone
Date date = new Date();
System.out.println(date); // system says GMT date
System.out.println(date.getTime()); // only prints time in milliseconds after January 1, 1970 00:00:00 GMT
System.out.println(sdf.format(date));
timeZone = TimeZone.getTimeZone(ZoneId.of("America/Los_Angeles"));
TimeZone.setDefault(timeZone); // set system timezone as GMT
sdf.setTimeZone(timeZone); // formatter also has a timezone
date = new Date();
System.out.println(date);
System.out.println(date.getTime()); // prints the same value as above, "not including timezone offset"
System.out.println(sdf.format(date));
// GMT and PDT times are same as getTime() only returns time in ms since UTC for the day ignoring timezone which is mostly used for formatting
Wed Mar 14 22:43:43 GMT 2018
1521067423108
2018-03-14T22:43:43+0000
Wed Mar 14 15:43:43 PDT 2018
1521067423125 // not includes timezone in getTime()
2018-03-14T15:43:43-0700 // formatting looks fine

The good explanation of why Date object taking Current time zone value ,
please refer this SO answer
EDIT.
here I am gonna add some important part of that answers.
java.util.Date is has no specific time zone, although its value is most commonly thought of in relation to UTC. What makes you think it's in local time?
To be precise: the value within a java.util.Date is the number of milliseconds since the Unix epoch, which occurred at midnight January 1st 1970, UTC. The same epoch could also be described in other time zones, but the traditional description is in terms of UTC. As it's a number of milliseconds since a fixed epoch, the value within java.util.Date is the same around the world at any particular instant, regardless of local time zone.

Date timezone issue

I have a UI where user can enter date. Now this date is converted to UTC format in my code which is inside an EJB.
My Query is if the browser in IST and my code is deployed in an server which in EST.
Now to convert to UTC from which timezone I need to convert the date from IST or ETC.
My code is like:
User enters a date in DatePicker. The value of DatePicker is assigned to plain Java Date Object.

You need to do IST to UTC
Your user is selecting date assuming it is IST. So in your server code you need to consider the user time zone before creating a Date object which will be in server time zone. Since server is in EST you need to convert it again to UTC before storing.
Most of the servers have time configured at UTC time zone, so only one conversion is all that is needed in that case.

When you get a Date its in the local time zone.
private static final DateFormat FULL_RFC822_DATETIME_FORMAT = new SimpleDateFormat("EEE, d MMM yyyy HH:mm:ss", Locale.US);
public static void date2() throws Exception {
FULL_RFC822_DATETIME_FORMAT.setTimeZone(new SimpleTimeZone(0, "GMT")); //frozen
Date d = new Date(); // in local time zone
System.out.println(d);
System.out.println(FULL_RFC822_DATETIME_FORMAT.format(d) + " GMT");
}
I get
Fri Dec 07 11:15:58 CET 2012
Fri, 7 Dec 2012 10:15:58 GMT
GMT + UTC are the same.

Why does an hour get added on to java.util.Date for dates before Nov 1 1971?

The following code appears to demonstrate a bug in java.util.Date whereby an hour gets added on if the local clock is set to GMT with DST adjustment on and the time is before Nov 1 1971. My first assumption is always that I've got it wrong. Can anyone see what's wrong (or is this really a Java bug)? What's significant about Nov 1 1971?
import java.text.SimpleDateFormat;
import java.util.Locale;
import java.util.TimeZone;
class JavaUtilDateBug
{
private static void demo() throws Exception
{
// UK developers usually have the clock on their development machines set
// to "Europe/London" (i.e. GMT with daylight saving). Set it explicitly
// here so readers in other countries can see the problem too.
TimeZone.setDefault(TimeZone.getTimeZone("Europe/London"));
Locale.setDefault(Locale.ENGLISH);
SimpleDateFormat dateFormat = new SimpleDateFormat("EEE MMM dd HH:mm:ss z yyyy");
String strJan1st1970Expected = "Thu Jan 01 00:00:00 GMT 1970";
String strJan1st1970Actual = dateFormat.parse(strJan1st1970Expected).toString();
System.out.println("strJan1st1970Actual: " + strJan1st1970Actual); // -> "Thu Jan 01 01:00:00 GMT 1970"
boolean jvmHasDateBug = !strJan1st1970Expected.equals(strJan1st1970Actual);
System.out.println("jvmHasDateBug: " + jvmHasDateBug); // -> true
// The anomaly only seems to affect times before 1 Nov 1971.
final String strNov1st1971 = "Mon Nov 01 00:00:00 GMT 1971";
assert strNov1st1971.equals(dateFormat.parse(strNov1st1971).toString());
}
public static void main(String[] args)
{
try
{
demo();
}
catch (Exception e)
{
e.printStackTrace();
}
}
}
My Java environment:
java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode, sharing)

There was a trial of British Standard Time between 27th Oct 1968 and 31st Oct 1971, which I suspect is what's causing this issue.
There's some details of the trial here:
http://en.wikipedia.org/wiki/British_Summer_Time#Single.2FDouble_Summer_Time
The timezone for Europe/London in Jan 1st 1970 was British Standard Time (GMT+1) so when you use a java.text.SimpleDateFormat to parse Jan 01 00:00:00 GMT 1970 it generates the correct epoch value equal to Jan 01 01:00:00 1970 in BST.
Then, due to the crappiness of java.util.Date, when you call java.util.Date.toString() it uses the default timezone for the current local as of now, which has changed to GMT and you get Jan 01 01:00:00 GMT 1970.

It's the locale. From http://en.wikipedia.org/wiki/British_Summer_Time
the British Standard Time scheme was trialled between 27 October 1968 and 31 October 1971, when Britain remained on GMT+1 all year.

I found a matching bug in Sun's bug database. Seems that they consider it a "historical inaccuracy" (the formatting apparently should produce "BST" as time zone rather than GMT - the hour would then be correct) and won't fix it, because deep down, the TimeZone implementation cannot handle places switching the name of their time zone.
As a workaround, you can explicitly set your time zone to GMT rather than "Europe/London". The problem then disappears.

This is not a bug.
You have set your default timezone to BST which is (GMT + 1), the GMT date of Jan 1 1970 00:00:00, when you parse this date using BST timezone as your default, it always displays time based on your current timezone (auto applies offset from GMT).
In this case it was GMT + 1 which is why your result was an hour off.