Hi, Avatica assumes that the underlying engine operates on relative time without time zone as opposed to global time (UTC). When you set a temporal value (e.g., a prepared statement parameter), Avatica adds the current offset to the passed time. When you read a temporal value, Avatica subtracts the current offset. This may lead to incorrect results if DST offset changes.
Consider that we have a timezone with DST, that works as follows. D1 and D2 are two consecutive days (e.g., 24 and 25 Oct): D2 00:00 GMT+2 -> D1 22:00 GMT D2 01:00 GMT+2 -> D1 23:00 GMT D2 03:00 GMT+3 -> D2 00:00 GMT D2 04:00 GMT+3 -> D2 01:00 GMT Now consider, that we want to save D2 00:00 GMT+2 using Avatica. On write, Avatica will advance the time by the TZ offset. On read, Avatica will subtract the TZ offset. The problem is that different offsets will be used, leading to the incorrect result. The associated logic is located in AbstractCursor and TypedValue classes. long initial = [D2 00:00 GMT+2].epochMillis() // D1 22:00 GMT long onWrite = initial + offsetAt(initial); // D2 00:00 GMT long onRead = onWrite - offsetAt(onWrite); // D1 21:00 GMT assert initial == onRead; // Fails The fundamental problem is that the current time offset is used, which might differ before and after adjustment. One potential solution is to enhance the reading part. It should check whether the offset after the subtraction is the same and if not - do the additional adjustment to restore the proper time. Do you have any objections to the proposed change? Regards, Vladimir.
