Hi Vladimir, your analysis seems correct to me, as well as your proposed solution.
Best regards, Alessandro On Sun, 28 Mar 2021 at 09:51, Vladimir Ozerov <ppoze...@gmail.com> wrote: > 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. >
