We Keep Coding

Changing Java Timestamp format causes a change of the timestamp

I'm a bit puzzled regarding the Java timestamp formatting functions as they seem to change the timestamp by a few minutes.
My Pivotal CloudFoundry app writes a new entry into a PostgreSQL 9.4.5 database. Doing so, I let PostgreSQL generate and store a timestamp for that entry (within the SQL statement I use 'now()' for that particular column).
All that works fine so far. Problems arise when I read the entry with my app because I have to format the timestamp to ISO 8601 (company policy) and this seems to change the timestamp. I've used this code:
public String parseTimestamp(String oldDate) {
System.out.println("String oldDate: " + oldDate);
TimeZone timeZone = TimeZone.getTimeZone("Europe/Berlin");
SimpleDateFormat oldDateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSSSS");
SimpleDateFormat newDateFormat = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss'Z'");
newDateFormat.setTimeZone(timeZone);
Date tempDate = null;
try {
tempDate = oldDateFormat.parse(oldDate);
} catch (ParseException e) {
//TODO
}
System.out.println("tempDate before format(): " + tempDate);
String newDate = newDateFormat.format(tempDate);
System.out.println("tempDate after format(): " + tempDate);
System.out.println("String newDate: " + newDate);
return newDate;
}
Output:
String oldDate: 2018-06-18 13:07:27.624828+02
tempDate before format(): Mon Jun 18 13:17:51 CEST 2018
tempDate after format(): Mon Jun 18 13:17:51 CEST 2018
String newDate: 2018-06-18T13:17:51Z
As you can see, the timestamp changed from 13:07 to 13:17. All the other queried entries also show a difference, varying between ~2 to 10 minutes. However, when I re-run the query, each difference stays the same. OPs told me that all involved systems have synchronised time and I'm not sure if system time should play a role here at all.
Does someone know what is going on?

First, I was really puzzled and thought, you might have found some kind of bug in SimpleDateFormat. Your code can be reduced to the following lines to show the same behaviour:
SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSSSS");
String str = "2018-06-18 13:07:27.624828+02";
System.out.println(str);
System.out.println(format.parse(str));
Result:
2018-06-18 13:07:27.624828+02
Mon Jun 18 13:17:51 CEST 2018
The parsed Date object got ten additional minutes (and some seconds).
Taking a closer look reveals the problem - it is NOT a bug in JDK:
Your millisecond-part is 624828 - these are six(!) digits (not three). 624828 milliseconds are about 624 seconds, which are 10 minutes and 24 seconds.
The SimpleDateFormat correctly summed up this additional seconds and minutes.
What's wrong too: Your date format contains five digits for the milliseconds part.
Solution:
The (new) Java Time API can handle larger fractions of a second - and also convert easily between different time zones:
String str = "2018-06-18 13:07:27.624828+02";
DateTimeFormatter pattern = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss.SSSSSSx");
OffsetDateTime date = OffsetDateTime.parse(str, pattern);
System.out.println(date);
System.out.println(date.withOffsetSameInstant(ZoneOffset.UTC));
Result:
2018-06-18T13:07:27.624828+02:00
2018-06-18T11:07:27.624828Z

Your input date contains micro seconds but SimpleDateFormat supports only milli seconds (up to 3 digits). When parsing the value with the flag lenient enabled the complete 6 digits are evaluated as micro seconds. So at the end you have 624 seconds that are added to the date additionally.
You can try to use the SSSSSS pattern with DateTimeFormatter that has been introduced in Java 8.
But you may have further issues. Your code parses the input date without the time zone information +02 that is included at the end. You should add one letter X for the ISO8601 time zone format. When formatting the date for outputting you use letter 'Z' that indicates time zone UTC. But you set time zone CET (Berlin). So the output date is not in UTC. The correct ouput in UTC for the specified input date is:
2018-06-18 11:07:27Z

Converting java.util.Date to java.sql.Timestamp results into wrong value

Server side code (server timezone is UTC):-
Date aDate = new Date();
java.sql.Timestamp aTimestamp = new java.sql.Timestamp(aDate.getTime());
Client side (Mobile app, timezone GMT +5:30):-
Hitting a service request which runs above code on server side
The issue is when i debugged on server, found following values :-
aDate.getTime() prints to -> 1470472883877 milliseconds i.e., Sat Aug 06 2016 14:11:23 GMT+0530
but
aTimestamp prints to -> (java.sql.Timestamp) 2016-08-06 08:41:44.109
It's kinda weird, i've no idea what's going on in conversion !! please help

UTC and GMT are formats.
java.util.Date and java.sql.Timestamp are independent of the timezone. They store a long time in ms for representing their inner state.
For information, Calendar is timezone aware.
So with Date or Timestamp, to differentiate GMT or UTC format in an output, you have to use a formater which outputs the date into string by being aware the timezone.
In your output : 2016-08-06 08:41:44.109, you don't use a formater which is aware of the timezone. It's probably the result of a toString() on the java.sql.Timestamp instance or something of similar.
What you consider as a conversion is not a conversion but a formatting since the timestamp stays the same between the two objects.
If you want to display in the UTC format, use the appropriate formater with a
SimpleDateFormat for example :
SimpleDateFormat dt= new SimpleDateFormat("MM/dd/yyyy hh:mm:ss z");
dt.setTimeZone(TimeZone.getTimeZone("UTC"));
String dateStringInUTC = dt.format(new Date(yourSqlTimestamp.getTime()));

The following is probably what you are looking for:
Calendar cal = Calendar.getInstance(Locale.GERMANY); // use your locale here
Timestamp aTimestamp = new Timestamp(cal.getTimeInMillis());
System.out.println(aTimestamp);
System.out.println(cal.getTime());
And the output:
2016-08-06 19:12:54.613
Sat Aug 06 19:12:54 CEST 2016

SimpleDateFormat returns "Sun Oct 10 00:00:00 BRT 2010" but insert "2010-10-10"

i have a code where i use a SimpleDateFormat:
String data = jTData.getText();
DateFormat formatter = new SimpleDateFormat("yyyy-MM-dd");
Date dataInserir = null;
dataInserir = formatter.parse(data);
System.out.println(dataInserir);
The output for this code if the string from the jTData.getText()is "2010-10-10" is:
Sun Oct 10 00:00:00 BRT 2010.
But, it is inserted in the database the value 2010-10-10.
The field is:
#Temporal(javax.persistence.TemporalType.DATE)
private Date data;
What am i missing that i'm not able to get an output like 2010-10-10 as a Date ?
And why is this inserting the value 2010-10-10 if the output is Sun Oct 10 00:00:00 BRT 2010?
Any help i'll be grateful, thanks.

I suspect you are confusing the nature of the java.util.Date class versus java.sql.Date. The first is a date and time-of-day, the second is date-only.
You marked marked your annotation as javax.persistence.TemporalType.DATE. The doc for that enum says simply:
Map as java.sql.Date
You said to store a date-only.
So what you are experiencing is a feature, not a bug.
If you want to store a date with a time-of-day, use the javax.persistence.TemporalType.TIMESTAMP annotation.
Back that with a timestamp type on the column in your database (should almost always be a timestamp-with-time-zone type).
Also, I recommend using the java.time framework rather than the troublesome java.util.Date and SimpleDateFormat classes. But that is a whole other topic.

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.

Java Timezone Conversion : Help Required [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Timezone conversion
I have to convert given time and timezone with some other timezone using Java code.
For Example :
I have to convert 28 Sept 2:00 PM IST in Canada timezone with considering DST (Day Light Saving Time) as well.
Can someone help me?

Try getTimeZone() and setTimeZone() along with Calendar class
TimeZone oztz = TimeZone.getTimeZone("Canada/Atlantic");
Calendar datetime = Calendar.getInstance( oztz );
See this link for all Time-Zones :
http://snipplr.com/view/23131/timezone-enum/

Probably you are looking for something like this :
Converting Times Between Time Zones

The Calendar class has built in methods for doing the conversion.
You can set the desired timezone with setTimeZone.
Also see the getTimeZoneOffset from the Date class.

You could use JodaTime and its support for different timezones.
Namely, if you know you have string ISO format or a specific known format (like it looks like), you could do something like:
DateTimeFormatter fmt = ISODateTimeFormat.dateTime().withZone("Asia/Kolkata");
DateTime newDate = fmt.parseDateTime([your input date]);
// You can manipulate your date here...
String newString = fmt.withZone("Canada/Atlantic").print();
This handles internally all Timezone matters, included DST.

Simple way is set Datetime and Timezone to Calender and getTime. Below is sample code which will set Timezone and user specific time.
Date date =new Date(2012,9,28,2,00,00); //Set time to Date
Calendar calendar = new GregorianCalendar(TimeZone.getTimeZone("Canada/Atlantic"));
calendar.setTime(date);
System.out.println("Timezone :: " + calendar.getTimeZone());
System.out.println("Time :: " + calendar.getTime());
Output:
Timezone :: sun.util.calendar.ZoneInfo[id="Canada/Atlantic",offset=-14400000,dstSavings=3600000,useDaylight=true,transitions=228,lastRule=java.util.SimpleTimeZone[id=Canada/Atlantic,offset=-14400000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=3,startDay=1,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]]
Time :: Mon Oct 28 02:00:00 GMT 3912
You will get all information from TimeZone useDaylight(true/false), dstSaving(1 hour for canada)
For more functionality of TimeZone please refer below link:
http://biese.wordpress.com/2006/10/23/java-daylight-saving-time-and-time-zone/
Here is link to get DayLightSavingTime information:
http://timeanddate.com/worldclock/clockchange.html?n=1187&year=2012