java.sql.Date varies if serialized in one time zone and deserialized in another

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)
======================================================================