We Keep Coding

SimpleDateFormat with pattern yyyyMMddhhmmss unable to parse date "20160327020727"

I am getting an exception when parsing date 20160327020727 with format yyyyMMddhhmmss. Note that the lenient is set to false.
SimpleDateFormat df = new SimpleDateFormat("yyyyMMddhhmmss");
df.setLenient(false);
try {
Date dt = df.parse("20160327020727");
} catch (ParseException e) {
e.printStackTrace();
}
It is parsing other dates with the same format and it is working as expected. Why is this happening?

CET changes to summer time the last Sunday of march, so there is no 2AM this day.
You go from 1:59 to 3:00

You are getting an error because that time does not exist in your default time zone.
Try setting the timezone to UTC by doing df.setTimeZone(TimeZone.getTimeZone("UTC"));
In CET on the last Sunday of march it changes to summertime -> No 2AM on that day.

Change it to "yyyyMMdd HHmmss", so you can parse it easily.

EST time conversion with daylight saving time

EST time conversion with daylight saving time it is coming wrongly
private void timeConversion() {
String s = "2016-08-29 1:40:00 AM";
DateFormat df = new SimpleDateFormat("yyyy-MM-dd hh:mm:ss a", Locale.ENGLISH);
df.setTimeZone(TimeZone.getTimeZone("EST"));
Date timestamp = null;
try {
timestamp = df.parse(s);
df.setTimeZone(TimeZone.getDefault());
System.out.println(df.format(timestamp));
} catch (ParseException e) {
e.printStackTrace();
}
}

The time zone EST does not respect any daylight saving time offsets:
TimeZone estTz = TimeZone.getTimeZone("EST");
System.out.println(estTz.useDaylightTime()); // prints 'false'
That is the time zone EST will always have a -5:00 hour offset to UTC.
This is probably due to some locations in Canada, Mexiko and Central America (Panama) not using DST but using EST all the year.
If you want a time zone with DST offset, you should use something like US/Eastern or America/New_York, etc:
TimeZone usEasternTz = TimeZone.getTimeZone("US/Eastern");
System.out.println(usEasternTz.useDaylightTime()); // prints 'true'

Get XMLGregorianCalendar date in EST time Zone

I am using TimeZone.setDefault(TimeZone.getTimeZone("EST")); to get the time zone EST and it is working fine to me. But sometimes I am getting time zone EDT when no one called this method in my project because of the default JVM time zone.
public getTimeInEST(XMLGregorianCalendar date) {
TimeZone.setDefault(TimeZone.getTimeZone("EST"));
DateFormat formatter = new SimpleDateFormat("dd MMM yyyy HH:mm:ss z");
formatter.setTimeZone(TimeZone.getTimeZone("EST"));
String newTime = formatter.format(date.toGregorianCalendar().getTime());
Date newDate = null;
try {
newDate = formatter.parse(newTime);
System.out.println("ESTDate : " + newDate)
} catch(ParseException e) {
System.out.println(e.getMessage);
}
}
Is there any other way where I get XMLGregorianCalendar date in EST time zone without using TimeZone.setDefault(TimeZone.getTimeZone("EST"))?

I suspect you should just pass the time zone to toGregorianCalendar. I'd also strongly recommend using full time zone IDs rather than abbreviations - after all, I suspect you really want Eastern time (EST and EDT) rather than just EST.
Also, there's no need to format a string value and then parse it - you can just use Calendar.getTime():
// Possibly...
public Date toDate(XMLGregorianCalendar date) {
TimeZone zone = TimeZone.getTimeZone("America/New_York");
Calendar calendar = date.toGregorianCalendar(zone, Locale.US, null);
return calendar.getTime();
}
Note that a Date value doesn't have a time zone - it's just an instant in time. The return value of Date.toString() is misleading in that it always uses the system default time zone, but there's no such thing as "a Date in the Eastern time zone".
I've included the "possible" in the comment as it's not really clear what you're trying to achieve here. This code is only useful if the XMLGregorianCalendar specifies the date/time but no time zone, and you want to assume it actually represents a value in the Eastern time zone, and convert that to an instant in time. Is that what you want?

SimpleDateFormat returns wrong date value during parse

I m facing a problem:I want to get current time of GMT TimeZone in long.
I m using the following code as given below:
TimeZone timeZoneGmt = TimeZone.getTimeZone("GMT");
long gmtCurrentTime = getCurrentTimeInSpecificTimeZone(timeZoneGmt);
public static long getCurrentTimeInSpecificTimeZone(TimeZone timeZone) {
Calendar cal = Calendar.getInstance();
cal.setTimeZone(timeZone);
long finalValue = 0;
SimpleDateFormat sdf = new SimpleDateFormat(
"MMM dd yyyy hh:mm:ss:SSSaaa");
sdf.setTimeZone(timeZone);
Date finalDate = null;
String date = sdf.format(cal.getTime());
try {
finalDate = sdf.parse(date);
} catch (ParseException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
finalValue = finalDate.getTime();
return finalValue;
}
As given in, above method
while formatting
String date = sdf.format(cal.getTime());
I m getting correct current time in GMT but as i do parsing by following code:
finalDate=sdf.parse(date);
Date got changed from current GMT time to 15:35:16 IST 2013 that is current time of my system.
I tried with Calendar as well in another way:
TimeZone timeZoneGmt=TimeZone.get("GMT");
Calendar calGmt = Calendar.getInstance();
calGmt.setTimeZone(timeZoneGmt);
long finalGmtValue = 0;
finalGmtValue = calGmt.getTimeInMillis();
System.out.println("Date......" + calGmt.getTime());
but still getting date as current time of my System Thu Jan 23 15:58:16 IST 2014 Not getting GMT current time.

You've misunderstood how Date works. A Date doesn't have a time zone - if you use Date.toString() you'll always see the default time zone. The long value in a Date is purely the number of milliseconds since the Unix epoch: it doesn't have any concept of time zone or calendar system.
If you want to represent a date and time in a particular time zone and calendar, use Calendar instead - but for getting "the current date and time as a long" you can just use System.currentTimeMillis(), which again does not have anything to do with the system time zone.
Additionally, even if you did want to do manipulation like this, you shouldn't be using string conversions. You're not conceptually performing any string conversions, so why introduce them?
If your aim is to display (as a string) the current date and time in a particular time zone, you should just use something like:
Date date = new Date(); // This will use the current time
SimpleDateFormat format = new SimpleDateFormat(...); // Pattern and locale
format.setTimeZone(zone); // The zone you want to display in
String formattedText = format.format(date);
When working with date and time APIs - particularly bad ones like the Java Calendar/Date API - it's very important that you understand exactly what each value in your system represents.

UTC timestamp not returning correct time

I get a date string from the server in EST so I convert it
example date 2013-04-16T11:56:07.15
incidentDate = l.item(0).getTextContent();
DateFormat dformat = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSS",Locale.US);
dformat.setTimeZone(TimeZone.getTimeZone("America/New York"));
Date timestamp;
try
{
timestamp = dformat.parse(incidentDate);
incidentDateLong = timestamp.getTime();
}
catch (ParseException e1) {
e1.printStackTrace();
}
the timestamp that gets returned is 1366113367015
If I plug that into a converter on this website to check the date
http://www.ruddwire.com/handy-code/date-to-millisecond-calculators/
the milliseconds does not seem to be the correct date, it gives me Tue Apr 16 2013 07:56:07 GMT-0400 (Eastern Daylight Time) which is not was was sent to me from the server.
When I go to convert the date back it pulls the date back even further away from the actual date
Date incDate = new Date(dateInMili);
DateFormat dformat = new SimpleDateFormat("MM/dd/yyyy hh:mm:ss a",Locale.US);
String dateStr = dformat.format(incDate);
Is something wrong with my formatter? I dont understand the problem

This is the problem:
TimeZone.getTimeZone("America/New York")
That's not a valid time zone ID. You want:
TimeZone.getTimeZone("America/New_York")
Note the underscore. Personally I think it's a shame that getTimeZone gives no indication that it hasn't actually found the time zone you've asked for, but it's been that way for a long time :(