The trick is to think of TIMESTAMP values in the DB as zoneless. There is no timezone. UTC is not the implicit timezone. There is no timezone.
Because the timezone is not stored in the database, the application needs to provide one. When you call getTimestamp(Calendar) you are saying "give me a java.sql.Timestamp object assuming that the value from the database is in timezone of the Calendar object I have provided". Which is why you'll see a typical implementation of getTimestamp SUBTRACT the offset of the calendar's timezone. On Mon, May 25, 2020 at 11:33 PM Ayelet Morris <[email protected]> wrote: > > Hi All, > I see in TimestampAccessor and in DateAccessor that the timestamp/date > received is already localized and the calendar is the same as the one > defined in the configuration as localCalendar, then the code only checks if > calendar exists and adds it's offset to the date. it creates an error in my > timestamp in some scenarios. > > I thought that maybe it is possible to check if the timestamp/date uses the > same calendar as defined in config and then not to use the offset on it, or > at least calculate the offset from the timestamp object calendar and not > always from 0... > > for example, to consider it in this code: > > @Override public Timestamp getTimestamp(Calendar calendar) throws > SQLException { > Timestamp timestamp = (Timestamp) getObject(); > if (timestamp == null) { > return null; > } > if (calendar != null) { > long v = timestamp.getTime(); > v -= calendar.getTimeZone().getOffset(v); > timestamp = new Timestamp(v); > } > return timestamp; > } > > > WDYT? > Thanks, > Ayelet
