Combine java.util.date with java.sql.Time

I have an extensive DATE-TIME conversion class, but I came across a script that I cannot solve:

I have java.util.date: Tue May 10 00:00:00 BST 2011
I have java.sql.time: 03:58:44

I need to create java.util.date: Tue May 10 03:58:44 BST 2011

The only approach I came up with:

public static Date getDate(Date date, Time time) { Calendar calendar=Calendar.getInstance(); calendar.set(date.getYear(), date.getMonth(), date.getDay(), time.getHours(), time.getMinutes(), time.getSeconds()); return calendar.getTime(); } 

Completely deprecated code and not working: java.lang.IllegalArgumentException in java.sql.Time.getYear (Unknown source)

Any ideas?

+4
source share
6 answers

java.sql.Time is just a wrapper over java.util.Date. You can use it as if you added two java.util.Date objects.

For example, set Calendar to java.sql.Time:

 calendar.setTime(time); 

Now extract the hour / minute / seconds fields, i.e.:

 calendar.get(Calendar.HOUR); 

Then set the Calendar object to java.util.Date and add these three fields to your time, i.e.:

 calendar.add(Calendar.HOUR, hour); 

And return the date:

 calendar.getTime(); 
+10
source

The easiest way is to simply add millions of seconds to create a new date, ala

 public static Date getDate(Date date, Time time) { return new Date(date.getTime() + time.getTime()) } 
+4
source

The vickirk solution was not so bad, but it has problems with the time zone, which leads to the fact that you watched less than an hour.

I believe BST stands for British Daylight Saving Time , which is GMT +0100. Now java.util.Date and its descendants are working with the numbers of milliseconds since midnight January 1, 1970 GMT . The time zone is not counted until you specify a date / time using toString() . And they use your local time zone for this, which seems to be BST. This means what is really stored in these objects,

java.util.date: Mon May 09 23 : 00: 00 GMT 2011
java.sql.time: 02 : 58: 44 GMT

When you add the internal values ​​(which getTime() retrieves), as suggested by vickirk, you get a date containing Tue May 10 01 : 58: 44 GMT 2011, resulting in Tue May 10 02 : 58: 44 BST 2011 on gating.

So the explanation is one hour less is that the time zone offset is applied twice when you align the values ​​separately, while it only applies once after adding, because you are stringfy only once now. Or, on the other hand, adding an internal point value in time 03:58:44 BST is equivalent to adding a time interval of 2h 58m 44s.

So, to get the 3h 58m 44s time interval encoded in java.sql.Time, you must compensate for the time zone offset manually. You do this by analyzing the time line β€œ00:00:00” with java.sql.Time, which will result in an internal value of -3600000 , which is equivalent to December 31, 1969 23:00:00 GMT, i.e. one hour before the era. This is a denial of the time zone offset.

 public static Date mergeDate(Date date, Time time) { long tzoffset = -(Time.valueOf("00:00:00").getTime()); return new Date(date.getTime() + time.getTime() + tzoffset); } 

Of course, all this dirty hacking is necessary, because you insist on interpreting the meaning of time as a time interval, while it really is a point in time.

+4
source

You can use this instead.

  public static Date getDate(Date date, Time time) { Calendar calendar=Calendar.getInstance(); calendar.setTimeZone(TimeZone.getTimeZone("UTC")); calendar.setTime(date); calendar.add(Calendar.MILLISECOND, (int) time.getTime()); return calendar.getTime(); } 
+2
source

Can you do

 java.util.Date newDate = new java.util.Date(sqlDate.getTime()); 
+1
source

try these

  public static Date getDate(Date date, Time time) { Calendar calendar=Calendar.getInstance(); calendar.setTime(date); Calendar calendar1=Calendar.getInstance(); calendar1.setTime(time); calendar.set(Calendar.MINUTE, calendar1.get(Calendar.MINUTE)); calendar.set(Calendar.SECOND, calendar1.get(Calendar.SECOND)); calendar.set(Calendar.HOUR_OF_DAY, calendar1.get(Calendar.HOUR_OF_DAY)); return calendar.getTime(); } 
+1
source

All Articles