Re: TIMESTAMP value binary transfer problem

Well, the server and the client are on the same development Windows 7 machine. I've done some testing using class in attachment and found out that results depend on time zone and daylight saving settings, in some zones results are always correct, in some are correct with daylight saving turned off, in some with daylight saving turned on, and so on.  Obviously there's some problem with incoming binary data or time zone compensation in TimestampUtils.toTimestampBin()

                               if (!timestamptz) {

                                               if (tz == null) {

                                                               tz = defaultTz;

                                               }

                                               millis -= tz.getOffset(millis);

                               }

I don't really understand why this compensation is needed in the first place, conversion in TimestampUtils.toTimestamp() takes no time zone in account with TIMESTAMP type. Anyway, getting different results depending on data transfer type is unacceptable.

There was a problem with some time zones from memory, in the uk for example 1970 had an odd daylight saving period and because 1970 is used in calculating the time values in the driver this skews the results in the driver. Using the current year fixes it when calculating times.

Maybe something to check.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.