Description
Name: rl43681 Date: 06/17/2003
A DESCRIPTION OF THE REQUEST :
java.sql.Date extends java.util.Date, and is in effect a time (in milliseconds) since the epoch, but where the hour, minute and second are set to zero by convention. When a java.sql.Date is serialized in one time zone and deserialized in another, the date (as reported by toString()) will often change, because that time may be on a different date in the new time zone. A serialized java.sql.Date should have the same toString(), regardless of where it is serialized and deserialized.
JUSTIFICATION :
java.sql.Date is supposed to behave like a SQL date, but does not do so. This is confusing.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Since java.sql.Date is used to represent SQL dates, not timestamps (there is java.sql.Timestamp for that), it would make more sense for java.sql.Date to store, say, a number of days since the epoch. This would make it serialize and deserialize as the same date, regardless of time zone.
CUSTOMER SUBMITTED WORKAROUND :
Extending java.sql.Date with the following, and using this instead, works around the problem.
package com.espc.support;
import java.sql.Date;
import java.io.*;
import java.util.TimeZone;
public class EspDate extends Date {
public EspDate(long time) {
super(time);
}
private void writeObject(ObjectOutputStream s)
throws IOException
{
long UTCTime=getTime();
long localTime=UTCTime+TimeZone.getDefault().getOffset(UTCTime);
s.writeLong(localTime);
}
private void readObject(ObjectInputStream s)
throws IOException, ClassNotFoundException
{
long remoteLocalTime=s.readLong();
long UTCTime=remoteLocalTime-TimeZone.getDefault().getOffset(remoteLocalTime);
setTime(UTCTime);
}
}
(Review ID: 188381)
======================================================================